IBM DeveloperWorks helps PHP developers “Discover five common database problems that occur in PHP applications—including database schema design, database access, and the business logic code that uses the database—as well as their solutions”.

Join Zend’s Education Programs Manager, Dhwani Vahia, in discovering the new Zend PHP 5 Certification.

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!)

Part 2 of 2 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 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.

Part 2 of 2 In this article I introduce patterns in the context of PHP 5. From a basic definition, I work through to a short example. I also describe the structure of a pattern and explain some of the principles that the classic patterns promote and deploy.