On SOLID ground with Object Oriented Design

Single Responsibility Principle

A class should have one and only one reason to change, meaning that a class should have only one job.

To put it simply, each class should have one task that it is assigned to. Imagine you have a handyperson and they are skilled at plumbing, carpentry, electrical maintenance, and painting. With each skill the handyperson picks up the greater chance that there may be an error in one of the jobs. Say they are tasked with fixing the sink and installing a new counter. If there is a problem with the counter installation then they may not be able to fix the sink. Instead by having a carpenter and a plumber do each task respectfully one job will not affect the other.

Each individual has there set skill and the only reason they change is due to issues related to their task and not unrelated tasks.

Open-Closed Principle

Objects or entities should be open for extension but closed for modification.

I good way to imagine this is to think of an artist. This artist has been using oil paint to create their commissioned artwork. As time goes on they start to experiment with colored pencils and find that they can create artwork to sell using them. It would be strange if they were asked to paint using oil and they found they no longer could use that media. What is more likely to happen is that they extend their skills to be able to create art in both pencil and oil.

Liskov Substitution Principle

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

A parent and their child have a landscaping business together. The parent is in charge of designing the landscape, while the child is in charge of the installation and maintenance. One day the parent can’t make it to the job site and the child is left to complete the contract. The customer expect that by the end of the day they will have a well planned new landscape. It is expected that the child, having inherited their parents skill for design, will plan and install the new landscape with no issue.

Interface Segregation Principle

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

A eager teenager has just reached that age that they can start driving and they are very excited. They practice driving with some adults and study the drivers education manual. The day comes to take the test and they are nervous, but they feel prepared for anything that can be tossed at them. The test starts and it is going well until question 24, “A vessel is wind rode when it is ____________.” Wait, this sounds like a question about sailing, not driving. Just like our teen, expecting a person to know how to do something that they don’t use is peculiar.

Dependency Inversion Principle

Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.

First let’s define a few things:

High-level Module: Class that execute an action with a tool

Low-level Module: The tool that is needed to execute the action

Abstraction: What connects the high-level and low-level modules

Say you have a drill and a bit set. The drill does not have one bit fused to it or the bit set is not fused to one drill. Instead you use the drill(high-level) with the bits(low-level) to drill a hole. Neither the drill or the bit set knows how the other does their job, just how to interface.

The SOLID principle are a great way to create code that is not prone to errors and is easy to fix if errors are found.