SOLID principles will make your code more flexible. Yes, you read that correctly. Today we’re outlining those principles so that you can better integrate them into your code.

History of SOLID Principles

Robert C. Martin, commonly known as Uncle Bob, originally gathered these principles together and set them aside as the “first five principles” in good development. Afterwards, Michael Feathers realized that these principles could be arranged into an easily remembered, albeit ironic, mnemonic: SOLID. Introduced in the early 1990s, these five principles are now a key piece of the Agile development. SOLID code allows a system to be written in such a way that it is easily maintained and expanded over time.

Single Responsibility Principle

Class and functions should each be responsible for one thing. A rectangle class that knows how to calculate its area and how to draw itself would be a violation of this principle. This is because this class would have two reasons to change: 1) you might want to change how is drawn; 2) you must change the area calculation. Either way a single change to either would require a recompile of the unchanged method. A Swiss army knife is a great example of a violation of this principle; if you had to change one part of the knife, you would have to take the entire tool apart. On the other hand, a block of kitchen knives would be an example of the principle since each knife has its own purpose. This is one of the simplest principles to remember but the most difficult to adhere to. For example, a survival knife…does it follow the single responsibility principle?

Open-Close Principle

Objects should be open for extension but closed for modification. We want to be able to add functionality without having to change existing code. One example of adhering to this principle is separating to classes with an interface. Then you can swap out the class that implements that interface later. Think of it this way: you wouldn’t do brain surgery to put on a hat.

Liskov Substitution Principle

This is often the most difficult principle to explain. What you should remember is that a child class should be a perfect substitute for the parent class it derives from. There may be additional functionality in the child that is not in the parent but all the functionality in the parent must be in the child. An example of a failure would be a square class from a rectangle class. Even though one would consider a square to be a rectangle, the rectangle class will require properties to define both length and width where the square requires only one of those. If another class requesting a rectangle class actually receives a square class there would likely be a refused request as not all of the properties of a rectangle class are used in a square class.

Interface Segregation Principle

In this principle, an interface should be used to isolate knowledge about the system from individual components. For example, neither Client A nor Client B should know about functionality that it never uses. The service can implement both interfaces without each client knowing the operations of the other. You should never have to know how to handle something that you never handle in the same way a bricklayer shouldn’t know how a brain surgeon operates.

Dependency Inversion Principle

This principle can be followed with the compile time (develop/design) dependency opposes the run time (execution/use) dependency. When something is designed we want it to be designed to a standard such that we can swap out whatever is actually going to be running at the time of utilizing it. You wouldn’t run a dedicated electrical line from the power station to your house, install it, and solder a lamp to it. Instead, we have a standard that determines what the parameters of the electrical current coming out of the wall and the parameters of the specific size and shape for the interfacing device. Lamp manufacturers design their lamps to meet these parameters, as do most of our electronic appliances.

Failure to adhere to these principles will leave code being fragile or rigid, so it’s best to keep these five SOLID principles in mind.


Leave a Reply

Your email address will not be published. Required fields are marked *