D is for the Dependency Inversion Principle

-

The "D" in SOLID stands for Dependency Inversion Principle. Again, another mouthful but pretty straight forward.

Inversion, not injection, is defined as:
Depend on abstractions, not on concretions.

i.e. Depend on interfaces instead of concrete classes.

Note: Dependency Injection is a way of putting this into practise, similar but not the same thing.

Popular posts from this blog

I is for the Interface Segregation Principle

-
The "I" in SOLID stands for Interface Segregation Principle. It's more of a mouthful to say than it is to understand. It states : Clients should not be forced to depend upon interfaces that they do not use. Succinct right? i.e. Keep your interfaces as small and modular as possible. It maximizes their potential for reuse and prevents clients/end users from depending upon functions/methods they don’t really need.
Read more

S is for the Single Responsibility Principle

-
The "S" in SOLID stands for Single Responsibility Principle, and it’s probably the principle that gets the most bad press. It states that each class should have just one responsibility. My take on this is that this principle is another way of saying Keep It Simple Stupid (KISS). To quote Robert Martin himself : A class should have one, and only one, reason to change. One of Uncle Bob's favourite examples is "an “Employee” class that calculates the pay and saves the employee data to a persistence store. If there's a change required in how pay is calculated, the class will have to be changed. If the DBA makes some changes to the database schema, the class will probably have to change as well." Here the "Employee" class has two responsibilities which violates the SRP. One is business logic related and the other data infrastructure related. According to the Single Responsibility Principle, these concerns shouldn’t reside in th
Read more

L is for the Liskov Substitution Principle

-
The "L" in SOLID stands for the Liskov Substitution Principle. In my opinion, this has the most complicated definition, but the most obvious implementation, you're probably doing this without thinking about it. This principle is named after Barbara Liskov, who  defined it in 1988 as : What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behaviour of P is unchanged when o1 is substituted for o2 then S is a subtype of T. Eh? Robert Martin defines it as : Derived classes must be substitutable for their base classes. In my mind, this is one of the most fundamental principles of Object Oriented Programming? Definitely a staple when learning Java at University (I certainly remember this. "Dog and Cat are both types of Animal …"). Dependency injection frameworks put this into practise by supplyin
Read more