SOLID Principles – Revisited

I recently rewrote an article on APIE, an article I originally wrote over 2 years ago. Now I am going to rewrite another article I wrote 2 years ago on the SOLID principles.

My views on the SOLID principles, have stayed largely the same, however my knowledge of these principles has matured. This hopefully means, I’ll be able to explain each principle in greater detail and be a lot more concise on each subject. I also like to think my writing style has matured and so I’m able to express myself better with less waffling, which is always a plus.

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