Today I learned what SOLID means.

For this week’s blog entry, I found an article on the SOLID principles that I found to be rather interesting. The article teaches and reinforces the popular object oriented principles that have stood the test of time in a way that other articles have failed to do. This article explains the programming definition and relationship with each principle, then applies a real-life example to further illustrate each principle, which is why I chose it. Instead of breaking down every principle, I’ve decided to highlight the ones that stood out to me the most.

For the first principle, “S” the “Single Responsibility Principle”, the article explains that this principle states that each class should only do one thing and uses the duck boat as a real-life example of people failing to follow this principle.  The duck boat tries to be both a car and a boat instead of serving one purpose, meaning that maintenance is doubled. When trying to maintain an application, if a class serves many functions, finding where a bug lies, and even just properly maintaining the application becomes inherently more difficult if each class is trying to do too many things at once.

“I” for “Interface Segregation Principle”. This principle explains that it is better to have five smaller interfaces than one monstrous one. The article uses the idea of a soup of the day on a menu not being important enough for everyone to be listed on the menu every day. If this was the case, there would need to be a different version of the full printed menu for each soup of the day, each a new implementation of the “menu” interface. By keeping the concrete detail of what the soup of the day is off the menu, this allows the restaurant to use a different interface for the soup of the day, asking the server.  I feel like this principle has strong ties to the “S” principle. If interfaces are kept segregated, they become cleaner and seemingly, keeps the responsibilities of the implementations more precise.

These two principles along with the other three form a strong list of guidelines for any developer to follow when writing object oriented applications at the very least. This article’s use of real-life examples is what separated it from the rest of the pack and is why I’ll remember what each letter of SOLID stands for.  I know I’ve violated several of these principles in the past but I hope to follow these principles when writing applications in the future to help future-proof my code and become a better developer overall.

Here is the link to the original post/article.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s