If I could start this post with some phrase this would be it :
“Hide your instance variables, hide your data structures, cause they’re accessing everything around here”
Jokes aside, in this post I’m going explain why exposing your classes internal variables or data structures is bad.
Continue reading Depend on behaviour not data.
This post will be all about the Strategy Pattern.
The intent is says that
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Again, like all computer science definitions this sounds confusion. So let’s break it down in pieces (literally).
Continue reading Strategy Pattern
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