Composite Pattern in PHP

About 2 years ago I was blogging about design patterns in PHP and then I stopped to pursue writing about NoSQL. Those days are over and I’ve decided I’d like to finish my series on design patterns.

Previously I covered all of the creational patterns which are useful with PHP and the majority of structural patterns. One structural pattern I never covered was the Composite pattern and so that’s what I’m covering today. The purpose of this pattern is to allow trees of objects (composites) to be handled interchangeably, regardless of if the node is a branch of a leaf node. What branch and leaf nodes are is revealed below.

Lets use a hard drive as an example, you have directories which you can think of as branches, and you have files, you can think of these as leaf nodes. Branches contain leaves just like directories contain files. Directories and files are both separate entities, but the goal of the composite pattern is have them interchangeable, as always this means they should implement the same interface. Example methods that they both share include updating the owner and group, changing permissions, fetching size, created date or last modified date, etc.

Continue reading

Proxy pattern in PHP

The next structural design pattern in this series is called the proxy pattern. You can think of these, just like any other proxy. The aim here is to create a class which takes full responsibility for the execution of another class.

Yup you got it… technically they are wrappers as well, however they aren’t labelled this way.

Continue reading

Bridge pattern in PHP

The bridge pattern is another structural design pattern. The design pattern states that the bridge pattern should decouple an abstraction from its implementation. That sounds a lot one of the main goals of OOP, programming to an interface using polymorphism and abstraction to achieve inversion of control.

As much as that’s what it sounds like, that’s not the goal of the bridge pattern, it’s more the means of achieving the goal. I like to think of the bridge pattern as a multi-dimensional strategy pattern. I’ve not covered the strategy pattern yet but you can think of it as providing an interface to build multiple strategies or algorithms which can be selected at run time.

The bridge pattern differs from this, in that you build two collections of strategies, where all strategies from one interface can make use of the strategies from the other interface. As an example lets assume you have a device strategy with 3 implementations (Phone, Tablet & Laptop), you also have 3 messaging strategies (Skype, WhatsApp, Facebook). The goal is to build an application where every device can interchangeably use every messaging platform using composition.

Continue reading

Flyweight pattern in PHP

The flyweight pattern is todays structural pattern of the day. Put simply, the flyweight pattern is used for breaking down a large domain model into a smaller domain model and a collection of tiny object-value classes called flyweights.

Flyweights can be useful when you have a collection of objects, that contain repetitive attributes and you want to share these attributes, the end goal being to save on memory usage.

Continue reading