绿色数据中心空调设计 书评_书评:PHP中的实用设计模式

绿色数据中心空调设计 书评

This review of Brandon Savage’s Practical Design Patterns in PHP will include my own opinions and impressions about both the book, and the aspect of self-publishing. Many thanks to Brandon for giving me a review copy.

这次对Brandon Savage的PHP实用设计模式的回顾将包括我对本书以及自我出版方面的看法和印象。 非常感谢布兰登为我提供了一份评论副本。

Design patterns are about common solutions to common problems. … they are concepts, not blueprints; ideas, not finished designs. … they add clarity to an otherwise difficult situation. – Brandon Savage, Practical Design Patterns in PHP

设计模式是关于常见问题的通用解决方案。 ……它们是概念,而不是蓝图; 想法,而不是完成的设计。 ……它们使原本困难的情况更加清晰。 – Brandon Savage,PHP中的实用设计模式

内容 (Content)

Starting out on a lighter, introductory note, Brandon explains the need for frameworks, argues that OOP doesn’t mean just wrapping stuff in classes, and goes into detail on why design patterns appear to be difficult to learn. He then continues with a mild introduction into SOLID principles, and lays the groundwork for more advanced concepts. He explains why each SOLID rule is important and what it means. Given that SOLID is a well established software design principle, it’s only natural to compare it against every pattern that’s about to be explained in the book. Or, to be more precise, to assess how well each pattern respects the SOLID principles, while providing the developer with its intended functionality.

布兰登从一个简单的介绍性笔记开始,解释了对框架的需求,认为OOP并不意味着将内容包装在类中,并且详细介绍了为什么设计模式似乎很难学习。 然后,他继续对SOLID原理进行温和介绍,并为更高级的概念打下基础。 他解释了为什么每个SOLID规则都很重要及其含义。 鉴于SOLID是公认的软件设计原则,因此很自然地将SOLID与本书中将要解释的每种模式进行比较。 或者,更准确地说,是在为开发人员提供其预期功能的同时,评估每种模式对SOLID原则的遵守程度。


If I express matters in Dreyfus model terminology, he claims the book is there to turn a novice into a competent level developer without subjecting them to advanced beginner mistakes when, in fact, such an approach to learning is not entirely possible – that’s just not how the human knowledge acquisition process works.


As it might not be overly evident from the ToC, the patterns explained in this book are, in order:


  • The (Abstract) Factory Pattern

  • The Singleton Pattern

  • The Builder Pattern

  • The Decorator Pattern

  • The Adapter Pattern

  • The Bridge Pattern

  • The Facade Pattern

  • The Strategy Pattern

  • The Mediator Pattern

  • The Observer Pattern

  • The Chain of Responsibility Pattern

  • The Iterator Pattern

  • The Composite Pattern

  • The MVC Pattern

  • The Domain Model Pattern

  • The Active Record Pattern

  • The Front Controller Pattern


With so many patterns covered (and most covered well), I was surprised to see a sentence such as “[…] For example, the Registry Pattern (not covered in this book)…“. Why not? The Registry Pattern is a popular pattern, and very simple to explain even if it isn’t exactly recommended nowadays.

涵盖了如此多的模式(并且覆盖得最多),我很惊讶地看到一个句子,例如“ […]例如注册表模式(本书未涵盖)…… ”。 为什么不? 注册表模式是一种流行的模式,即使现在不完全推荐,也很容易解释。

Pattern by pattern, each is explained well and most are followed by code examples demonstrating their potential implementation, though I do have a gripe with the factory pattern example with the cache.


The pattern is realized on an example of different caches – APC and Memcache – and both are spawned through a factory, which is injected into whichever service needs a cache component.


It makes sense to me, but I can see less experienced people wondering why one might actually need the Factory step at all, and not simply type hint the cache interface itself in the constructor, requiring the injection of the cache object itself, and not its factory. The current example features both a Factory interface and a Cache interface, and at the very least, one seems like a surplus. This was never explained in a mid-level developer approachable way, and I fear it may be confusing to some. I’m also less than happy with the Bridge pattern’s explanation – it seemed lacking, like it was only scratched at the surface, never to properly return.

这对我来说很有意义,但是我可以看到经验不足的人想知道为什么实际上可能真的需要Factory步骤,而不是简单地在构造函数中键入提示缓存接口本身,而需要注入缓存对象本身,而不是注入缓存对象本身。厂。 当前示例同时具有Factory接口和Cache接口,并且至少看起来有些多余。 从来没有以中级开发人员易于理解的方式来解释这一点,我担心这可能会使某些人感到困惑。 我对Bridge模式的解释也不太满意–似乎缺乏,就像只是在表面划伤了,永远无法正确返回一样。

On the other hand, I absolutely loved the Composite pattern explanation and its demonstration on very interesting Tree examples – the author builds a composite tree with an arbitrary number of nested node levels which applies fantastically to menu construction, hierarchy representation, and more – and I was particularly thrilled with the Decorator pattern explanation. It was done in a very approachable way and on good, usable examples. This pattern in particular was one I’ve always had difficulty explaining to people out of the blue when asked, and I’ve yet to find a better breakdown than in this book.

另一方面,我非常喜欢Composite模式的解释及其在非常有趣的Tree实例上的演示-作者用任意数量的嵌套节点级别构建了一个Composite树,该层次结构极大地适用于菜单构造,层次结构表示等等。对于装饰器模式的解释特别满意。 它是通过非常平易近人的方式以及良好,可用的示例完成的。 特别是这种模式,当我被问到这个问题时,我总是很难向别人解释,而且我还没有找到比这本书更好的分类。

忽视模型 (Neglect of Models)

In one instance of the book, Brandon says that models are the heaviest lifters of an MVC application, containing all the business logic and validation code. This is a statement that’s far too absolute for me to accept – off the top of my head I can think of an example where this is not true: Laravel. With Laravel 5 coming out and adding Form Requests, the models will be growing even lighter.

在本书的一个实例中,布兰登说,模型是MVC应用程序中最重的模型,其中包含所有业务逻辑和验证代码。 这是一个绝对让我无法接受的声明-我脑中浮现出一个不正确的例子:Laravel。 随着Laravel 5发布并添加Form Requests ,模型将变得更加轻巧。


Granted, some people tend to put everything and the kitchen sink into the models, but there are people who put the same amount of god-code into controllers, too. My experience and preference say that everything framework-related should be very light (small controllers, small models, small or no views), and everything service-related (services, plugins, libraries, helpers) can be as fat as they need to be, as long as they’re inter-operable between frameworks. That’s personal preference though, I suppose. One other thing struck me as odd, though:

当然,有些人倾向于将所有内容和厨房水槽放入模型中,但也有人将相同数量的上帝代码放入控制器中。 我的经验和偏好表明,与框架相关的所有内容都应该非常轻巧(小型控制器,小型模型,小的视图或没有视图),而与服务相关的所有内容(服务,插件,库,助手)可以像它们需要的那样胖。 ,只要它们可以在框架之间互操作。 我想那是个人喜好。 不过,另一件事让我感到奇怪:

Creating good models is one of the most complicated tasks any developer tackles. For a long time, the Zend Framework documentation held that there was no Zend_Model class because creating a model is the bulk of an application development process. To create a Zend_Model would be to assume that everyone could or would want to use the same model structure, which would be impossible For the same reason I haven’t included any code in this chapter.

创建好的模型是任何开发人员都要解决的最复杂的任务之一。 很长时间以来,Zend Framework文档认为没有Zend_Model类,因为创建模型是应用程序开发过程的大部分。 创建Zend_Model就是假设每个人都可以或想要使用相同的模型结构,这是不可能的。出于同样的原因,我在本章中没有包含任何代码。

While this does make sense, exemplifying the value, gateway and storage object in the simplest of manners would have been incredibly beneficial to people being introduced to the domain model pattern for the first time. The Domain Model Pattern was, in my opinion, too neglected and far too theoretical in this book.

尽管这确实是有道理的,但以最简单的方式举例说明值,网关和存储对象对于第一次被引入域模型模式的人们来说将是不可思议的好处。 在我看来,本书中的领域模型模式太过被忽略和过于理论化。

知识的诅咒 (The Curse of Knowledge)

Throughout the book, Brandon makes references to advanced concepts (ORM, inheritance, dependency injection) and third party content without linking to it (Gang of Four), assuming the reader is familiar with it all. The Gang of Four in particular is mentioned on several occasions, and could use at the very least a link to Design Patterns – else the “novice” and “advanced beginner” reader will just glance over the sentence in confusion.

在整本书中,Brandon都引用了高级概念(ORM,继承,依赖项注入)和第三方内容,但未链接到该内容(“ Gang of Four”)(假设读者已熟悉所有内容)。 特别是在多个场合中提到了“四人帮”,它们至少可以使用到“ 设计模式 ”的链接-否则“新手”和“高级初学者”读者只会对句子感到困惑。

In other cases, the paragraph structure is written in a way that’s far beyond the level of understanding for a novice to intermediate user:


It’s an age old question many developers struggle with all the time: if I am working to invert my dependencies and not create objects inside my classes, how do I go about creating the dependencies that I need during runtime that can’t necessarily be injected?


This is not at a level that’s consumable by the reader who would need this book to become familiar with the patterns. The reader who understands this sentence in full is likely already fully familiar with all the patterns in the book, thus bringing into question the real target audience. I believe this is due to Mr. Savage suffering from what is known as “the curse of knowledge“.

对于那些需要本书来熟悉模式的读者来说,这不是一个可消耗的水平。 完全理解这句话的读者可能已经完全熟悉本书中的所有模式,从而使真正的目标读者产生疑问。 我认为,这是由于萨维奇先生遭受了所谓的“ 知识的诅咒 ”。


Wikipedia defines it as such:


The curse of knowledge is a cognitive bias that leads better-informed parties to find it extremely difficult to think about problems from the perspective of lesser-informed parties.


The curse of knowledge is a very common occurrence in professionals who aren’t formally trained to pass on what they know, but is also something that does lose effect with time, experience and feedback. This is also why we at SitePoint encourage people to give us honest feedback about our posts, and is why we try to make things simpler and more streamlined with every new publication. No one is immune to the Curse – some are just more affected by it.

知识的诅咒是在没有经过正式培训以传授所学知识的专业人员中很常见的情况,但是它也会随着时间,经验和反馈而失效。 这也是为什么我们在SitePoint鼓励人们对我们的帖子提供诚实的反馈的原因,也是为什么我们在每本新出版物中都尝试使事情更简单,更精简。 没有人能幸免于难-某些人受到的影响更大。

自我出版的瘟疫 (The Plague of Self-Publishing)


In recent years, self-publishing seems to have really taken off. Those that don’t resort to Leanpub go fully solo, like Brandon did with this book. While this approach does indeed speed the process up and allows experts to put quality content into the hands of interested parties at an alarmingly rapid pace, it also allows for more mistakes, bad content, and typos to slip through.

近年来,自我出版似乎真的起飞了。 那些不求助于Leanpub的人完全是单人,就像布兰登(Brandon)所做的那样。 虽然这种方法确实确实可以加快流程,并允许专家以惊人的速度将高质量的内容交付给感兴趣的各方,但它也允许更多的错误,不良内容和错别字出现。

Most of the problems that plague other self-publishing writers also, unfortunately, plague this book. Lacking an experienced editor, there seems to have been no guidance on content, form or even grammatical and syntactical accuracy – something people who are native to a language often mess up.

不幸的是,困扰其他自出版作家的大多数问题也困扰着这本书。 缺乏经验丰富的编辑,似乎对内容,形式甚至语法和句法的准确性都没有任何指导-语言固有的人经常会搞砸。

Thinking that native speakers don’t make mistakes and thus don’t need formal editing is akin to, for example, a Y-based company hiring someone from country X to proof-read their X-language version of the site on the sole grounds of the proofreader being a native speaker of language X. You really wouldn’t want to hire me to proofread your Croatian version of a website even though it’s my native language, but you’d be hard pressed to find a better English language editor.


结论 (Conclusion)

As an advanced user, I had previous knowledge of most if not all the patterns explained in the book. However, the explanations I went through were well formed and approachable to an intermediate user – though in my opinion, not to one of lower skill. While the content of the book is very good and Brandon is excellent at demonstrating in code what the theory describes, I feel like the book as a whole is far too complex for the newbie developer to get anything tangible out of.

作为高级用户,我以前对本书中解释的大多数(如果不是全部)模式都有了了解。 但是,尽管我认为,我所经历的解释是正确的,并且对中级用户来说是可以理解的,但对较低技能的人而言却不是。 尽管这本书的内容非常好,并且Brandon擅长在代码中演示理论所描述的内容,但我觉得这本书对于新手开发人员来说太复杂了,无法得到有形的东西。

The PHP community in general, it seems to me, is suffering from a sort of “missing link” syndrome where we have the absolute beginner books (“this is echo, this is a function, this is a php tag”) and the intermediate++ books like this one, or anything Sturgeon, Jones, Hartjes and others have put out, but there’s a middle ground that remains void of quality content and can only be conquered via the good old “throw me into the fire” approach.


That said, if you’re an intermediate developer looking to get into patterns and out of those awkward nods at conferences where people standing around you talk about them but you don’t understand a thing – definitely get this book. If you’re a newbie, I can’t recommend you buy this – not just yet. Master your “echos” first, learn what Composer is, then sink your teeth into this one.

就是说,如果您是一位中级开发人员,希望能在会议上站着的人谈论他们但对您一无所知的会议上尴尬的点头,却不了解其中的内容,那么绝对可以。 如果您是新手,不建议您立即购买。 首先掌握您的“ echos”,了解什么是Composer,然后全心投入。

In fact, if you ARE an advanced beginner (beginners should start at the very basics) who’s interested in patterns nonetheless, I applaud you and offer the following resources to look at before you dive into this book:


Content-wise, I’d give the book a 4/5, but taking into consideration the rush job it appears to have been near the end, the typos and language errors (though to be fair, there is a typo submission Github repo which I’ve already polluted with fixes) and the evident lack of professional guidance along with some oddities that I personally believe will embed wrong values into newbies stumbling onto this book (starting class names with numbers in various code samples), I’m ending the final score at 3/5.



翻译自: https://www.sitepoint.com/book-review-practical-design-patterns-php/

绿色数据中心空调设计 书评

参与评论 您还未登录,请先 登录 后发表或查看评论


  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
©️2022 CSDN 皮肤主题:编程工作室 设计师:CSDN官方博客 返回首页
钱包余额 0