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

What is APIE – Revisited

You’ve probably heard of APIE. If you haven’t, the most basic explanation is, “APIE is an acronym for the 4 paramount concepts within OOP, namely abstraction, polymorphism, inheritance and encapsulation.”

Each of these concepts is a huge discussion point in its own right, then there’s how they all fit together to form OOP. Many people have written multi-hundred page documents and book explaining these principles in depth and how to make use of them within different programming languages. Needless to say, I’m not going into that detail and I’m solely going to be discussing the language agnostics. By the end of this article, I hope to have explained each of the four concepts, covering a mix of what they are; how you should make use of them and how they all work together to keep you your code clean and human friendly.

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