My friend Kevin Schroeder recently released his latest book “You Want to Do What with PHP?” This book isn’t for everyone, click on inside and I’ll help you decide if it’s right for you.

p. !

p. !

Like 10,000+ piece puzzles? Got 2 hours to kill? SEO important to you? If you answered yes to any of these, then IBM wants the next two hours of your life. Tyler Anderson has released a PHP tutorial on developerWorks that is part 1 of a 2 part series detailing how to build an application to track SEO information for a set of domains. I’m seeing a muti-service Googlefight in the works. (How I do love improperly applying technology!)

[ continued from part 1 of PHP Patterns: The Visitor Pattern ] Discussion Our Visitor implementation could bear one significant [...]

Part 1 of 2

In a previous article I introduced the Composite pattern – as neat a way
of organizing components at runtime as you could want. To recap, a composite
structure is a tree of components, all of which implement the same core type.
This feature enables you to treat the whole tree, a sub-tree or an individual
component interchangeably. Think about a shape in a drawing program: you can
select, drag and/or transform it. Select and group multiple shapes, and you
can perform the same operations on the collection as you did on the individual
component.

Components in a composite relationship are good at working with one another.
Called by a client, an object performs the required operation and then invokes
the same method upon each of its children. Each child then repeats the process,
until the whole tree has responded to the client’s message.

This is neat, but it carries with it a certain danger. Because it is so easy
to build composite functions into a type, it’s tempting to extend the remit
of your classes beyond their strict responsibilities. This kind of feature
bloat makes for unwieldy and error-prone code. You start by building in core
functions, such as transform() and move(). Then you
find yourself straying into the gray area of object persistence with
save(). Before you know it, you’re adding more and more
increasingly tangential operations to the type – not because the type needs
each operation integrally, but because each operation needs easy access to
every component in the structure.

Composites are good at traversing themselves, and for that reason they attract
new methods. We can address this problem by extracting these methods into their
own type, and by generalizing traversal so that such objects can be transported
to every node in the tree. This is known as the Visitor pattern.

Part 2 of 2

Composite provides a mechanism for grouping multiple components together
under a single interface at runtime, and Visitor is a natural way of
performing operations across the resulting structure. These patterns can be
used in isolation, but they are so naturally suited that they invariably end
up in the kitchen together at parties.

Part 1 of 2

One of the great strengths of pattern oriented design is its viral nature. That is,
the way that one pattern tends to create conditions ideal for the application of
another pattern, which itself then benefits from yet another. Of course, this is
also one of the greatest weaknesses of the approach. Pick the wrong patterns, and
you are easily beguiled into a creating a system that is poorly suited for its
purpose. Assuming, though, that you select carefully, the complementary nature
of many patterns can be useful. As your projects throw up design challenges,
you will often find that ideal solutions are already documented in the classic
pattern catalogs.

Over the next two articles, I will examine two patterns that work well together.
Composite provides a mechanism for grouping multiple components together
under a single interface at runtime, and Visitor is a natural way of
performing operations across the resulting structure. These patterns can be
used in isolation, but they are so naturally suited that they invariably end
up in the kitchen together at parties.

Part 2 of 2

In this article I show you how to use the Observer pattern to build a flexible
broadcast-style relationship between a central component and the objects that
care about it.

Part 1 of 2

The Observer pattern is perhaps most often encountered in traditional graphical user
interface desktop applications. It is an excellent way of ensuring that disparate
display components reflect changes at a system’s core. As we shall see, though, it
remains a powerful technique in a Web-oriented environment.

In this article I show you how to use the Observer pattern to build a flexible
broadcast-style relationship between a central component and the objects that
care about it.

First though, in preparation for a running example, I take a look at object
mocking a great technique for test-driving code.