Let’s talk about the Template Method Pattern. This pattern is from the Behavioral family. And it’s very easy to understand.
The intent is that we define an method with an algorithm that cannot be changed, but allow subclasses to be deferred some of the algorithm steps.
Continue reading Template Method Pattern
This post is about the Adapter Pattern. Like the Decorator Pattern this one is also a Structural pattern.
What this patterns does is it allows the client to use different types of classes through a common adapter. These classes are called adaptee and they don’t have to change in any way to conform to our client.
Instead, an adapter is created to, well, adapt (no pun intended) to our client objectives.
Continue reading Adapter Pattern
This is probably one of the most used patterns for GUIs, one reason for this it’s because it allows a great level of decoupling inside an application, great extensibility and it is super Single Responsibility & Open and Closed friendly.
Continue reading Observer Pattern
And this is my first post on design patterns. I’ll start with the decorator pattern.
The decorator pattern is part of the Structural Patterns.
This is a very simple pattern to understand, but it allows great extensibility in runtime without using class inherence.
Continue reading Decorator Pattern
And last but not least, the D in SOLID for Dependency Inversion Principle (DIP).
This is probably one of the hardest principles to understand or implement. But once you nailed it, it’s very hard to go back.
Continue reading Dependency Inversion Principle
The I in SOLID is for Interface Segregation Principle (ISP).
This is the fourth principle, and it’s a very easy one to understand, it’s all about decoupling your classes and extensions. The intent is that:
Clients should not be forced to depend upon interfaces that they don’t use.
Continue reading Interface Segregation Principle
This is the third post about SOLID principles.
In this post I’m going to discuss the Liskov Substitution Principle. Somehow it’s an addition to the Open and Close principle in way that the derived classes should extending the base classes without modifying it.
Continue reading Liskov’s Substitution Principle
This is my second post on SOLID principles.
This time around I’ll talk about the Open and Closed principle. This principle in a nutshell means that a class, method and functions should be open for extension but closed for modification.
Continue reading Open and Closed Principle
This is my first post of the SOLID principle series. SOLID stands for:
- Single Responsibility Principle
- Open and Close Principle
- Liskov’s Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
So what’s a design principle and what do we use it for ?
Very roughly, they are guidelines that a developer can follow to avoid choosing a bad design. These principles allows us to write better code that avoid rigidity, fragility and immobility. Rigidity is when your code is too tied to other parts of the system. Fragility is when your code changes can break other parts of the system. Immobility occurs when the code is to hard to port to a different project because it lacks versatility and adaptability.
Continue reading Single Responsibility Principle