Site Loading

A look into SOLID principles

In an effort to look into how I can improve my code and the code bases I work on at work and the projects I have at home, I have decided to look into the SOLID principles and what they mean.

The idea behind the Solid principles are are to get you the developer to think about the classes / code you are writing before you begin.  The way I see these principles are that they are a great guide to help plan out what we are trying to achieve.  This way we don’t just dive straight into the problem we are trying to solve but we take the time to think it through.  All of the great developers I know and have had the privilege to work with have helped me to see what these principles are and how to put them into practice.  To often we look at this with a purely academic mindset rather than with practical outlook, so lets see what each of these mean and how to do it in a real life situation:

 What does it stand for

  • Single Responsibility Principle
  • Open Closed Principle
  • Liskov Responsibility Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

 Single Responsibility Principle

This principle here is stated that each class should have a single responsibility and and single reason to change.  The second part of that explanation really threw me until I saw an example.  In the example the class in question was asked what would make this class change.  If the answer was multiple things then the class needed to be split up into multiple classes.  So for example if the class handles the

 

Open Closed Principle

For some reason this always reminded me of Robocop!  Why, because the shortened version of this is OCP.  Anyway this principle can be stated that a class is open for extension but closed for modification.  This can easily be explained by saying that instead of changing the original class the class can be extended to alter its behaviour.  An obvious implementation of this is inheritance.  With the use of a base class the functionality can be extended.  The benefits of this are of course unit testing because the original has not been altered in any way.

 

Liskov Responsibility Principle

The Liskov responsibility principle revolves around the use of of sub types or classes.  In Object oriented programming if you have a base class of type Animal and a class that extends Animal called Dog.  When the type Animal is used in the code, it should be able to be interchangeable with the type Dog with no ill effects.

 

Interface Segregation Principle

The interface segregation principle states that the clients should not be forced to depend on the items they do not require.  The way that this work is that if a class is dependant on another class, the interfaces between them should only expose what the client needs.

 

Dependency Inversion Principle

The dependency inversion principle has another name, Inversion of control.  The way this principle works is that that the the way that a solution is put together, the pieces involved are depending on abstractions rather than concrete implementations.  Now you may ask, what does this really mean?  Well if you had Class A which used Class B.  You could just instantiate B in Class A, but what this principle is trying to help you do is rather to rely on an interface that will be instantiated at runtime.  This means that rather than instantiating the class at compile time you wait until runtime to sort it out.  Which ties in to the interface segregation principle, so you should not be forced to see more than they require.  This also helps with keeping your code clean and your dependencies light, so if something has to change the impact is low.

Close