The interface segregation principle (ISP) is concerned with the way clients access the functionality developed in another class. It states that clients should not be forced to depend on functionality they don't use.

Following this principle has several upsides. On one hand, it protects your objects from depending on things

In 1987, while delivering a keynote on data abstractions and hierarchies, Barbara Liskov introduced the idea that would eventually become the Liskov substitution principle. The following is a modern (and very formal) description of the principle:

Let Φ(x) be a property provable about objects x of type T. Then

The Open Closed Principle is responsible for the 'O' of the S.O.L.I.D principles. Originally coined by Bertrand Meyer, it states that:

Software entities (classes, modules, functions, ...) should be open for extension but closed for modification

It seems like an incredibly simple principle, but it's behind most

The Single Responsibility Principle is probably the most confusing of all 5 S.O.L.I.D principles. It took me quite a while to understand why it's an important thing, and where to apply it. The phrasing has changed through the years, but in most places, you will find

Dependency injection is one of those techniques that carry around a bad reputation for being overly complicated and hard to understand. In reality, DI(you guessed it, dependency injection) doesn't need any complex framework or fancy library to be useful, you can start using it very easily.

Let's start with