Chronicles of a Gray World

http://devzone.zend.com/node/view/id/1684

http://devzone.zend.com/node/view/id/1734

http://devzone.zend.com/node/view/id/1755

Or the link to the pdfs:

http://devzone.zend.com/content/pdfs/PHPinAction_part1of3.pdf

http://devzone.zend.com/content/pdfs/PHPinAction_part2of3.pdf

http://devzone.zend.com/content/pdfs/PHPinAction_part3of3.pdf

But you always have to be careful to get a second opinion (and a third and fourth). I consider that there are some conceptual errors or that some of the explanations left incomplete.

For example, about the Strategy pattern, saying that the purpose is to create reusable components or plugins is an incomplete concept and even incorrect. Usually design patterns have the purpose of enhancing code reusability, conforming a common base of design strategies. Plugins creation is but one of the posibilities where the Strategy pattern can be used, however the purpose of Strategy is to decouple an algorithm from its host, for example, an object may have sorting capabilities, but we know there are many sorting algorithms, or, in other words, different sorting strategies. The object receives sorting strategy object which decides how to sort without knowing how it’s actually done, on the other hand the sorting strategy object does the sorting without knowing anything about the object where the sorting is actually done (this way the Strategy objects can be reused out the original context, and changed without refactoring the original object).

The Strategy pattern can be confused with the Bridge pattern, as their UML graphic is almost the same. The Bridge pattern has as purpose decoupling an abstract data type from its implementation, for example a “Colection” object can be is implemented using arrays, linked lists, trees, etc. Using Strategy and Bridge together is usually known as policy-based design.

I don’t recommend using the Null pattern, specially when the existence of null is recognized by the language, and specially if it’s used to overlook a null result on a function as suggested on the book. If a function has the option of returnin null is for a reason, and checkin the output is not only necessary but adequate. In the example given by the book is coherent that a search may give a null result, indicating that the object being searched doesn’t exist, you should be the one checking the nullity of the result and act accordingly. On the other hand, it’s not coherent that the function returns an object when ther is not one, even if the object represents the inexestence of an object (there is a null language construct for that purpose).

About the explanation of the Iterator pattern, it fails to fully explain the reason of this pattern, specially because it tries to compare iterators with arrays. The purpose of iterators is simply to keep a common interfase for going through item list one item at a time, without knowing what’s the actual implementation. An array is an implementation, it doesn’t make any sense to compare it with iterators.

Finally, the Composite pattern is confused with the Tree abstract data type. The use of Composite implies tree structures but is mora than just that, conceptually speaking. A composite is an object that allows to perform actions over more than one object as if it were only one, for example, a drawing is a composite of strokes, figures, colours and even other drawings.