SOLID Design Principles

I: Interface Segregation Principle (ISP)

The Interface Segregation Principle states that clients should only implement interfaces they actually use. They should not be forced to implement interfaces they do not use. Wikipedia: "many client-specific interfaces are better than one general-purpose interface" What this means is that we should split large and fat interfaces into several small and lighter ones, segregating it so that smaller interfaces are based on groups of methods, each serving one specific functionality.

L: Liskov substitution principle (LSP)

The Liskov substitution principle talks about inheritance. It specifies how we should design our classes so that client dependencies can be replaced by subclasses without the client seeing the difference. Wikipedia: "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program" While there might be some specific functionality added to the subclass, it has to conform to the same behavior as its base class. Otherwise the Liskov principle is violated.

S: Single responsibility principle (SRP)

The class should have only one reason to change.

D: Dependency inversion principle (DIP)

The dependency inversion principle states that entities should depend on abstractions and not on concretions. That is, a high level module should not depend on a low level module, rather the abstraction. Wikipedia: "One should depend upon abstractions. Do not depend upon concretions." The DIP can be used anytime a class needs to call a method of another class, or shall we say send a message to it.

O: Open/closed principle (OCP)

The open/closed principle states that a class should be open for extension but closed for modification. Wikipedia: "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" The open for extension part means that we should design our classes so that new functionality can be added if needed. The closed for modification part means that this new functionality should fit in without modifying the original class. The class should only be modified in case of a bug fix, not for adding new functionality.