SOLID Principles – Software Craftsmanship Calendar Topics

The SOLID Principles are a set of Object Oriented Design Principles that are very interrelated and when followed can improve your code. Additionally, they make a great acronym that implies the benefits of using the principles. In 2011, at NimblePros, we made a calendar of Software Craftsmanship Principles and made humorous images to go along with them. We continued making the calendar for three more years and then missed 2015. Now we’re making a software craftsmanship calendar for 2016. Please back the calendar on Kickstarter, so there will be a 2016 edition.

Single Responsibility Principle

While it might seem useful at the time to just keep this stuff together, you may eventually realize it isn’t.

SingleResponsibilityPrinciple

Avoid tightly coupling your tools together.

Open Closed Principle

It’s important that your code be open to extension while being closed to modification. This means that you should be able to add additional functionality without significantly altering the existing functionality. Remember the dangers of changing code; bugs can easily be created.

OpenClosedPrinciple

Brain surgery is not necessary when putting on a hat.

Liskov Substitution Principle

Any class implementing an interface needs to be substitutable for that interface. For example, you can’t have missing functionality when implementing your interface, or it’s not really substitutable. Developers shouldn’t need to be careful about using a specific implementation of an interface. That was the point of using an interface.

LiskovSubstitutionPrinciple 

If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction.

Interface Segregation Principle

Your interface should match only the needs of its users. If you pile on too many features to your interface, you make it hard to implement and difficult to use. The implementations are also likely violating the Single Responsibility Principle just to implement your interface.

NP-Interface-Segregation

Tailor interfaces to individual client’s needs.

Dependency Inversion Principle

Don’t get too specific on your dependencies. Make sure that you’re depending on something stable. This is often some kind of an interface. In our example below, an outlet and a plug make the connection nicely. You don’t want to hard-code specifically to the connection you have; you might need to change your connection at some point.

NP-Dependency-Inversion

Would you solder a lamp directly to the electrical wiring in a wall?

I hope you enjoyed these SOLID principle pictures. And if you want to see more of this kind of humorous take on important software development principles and ideas, back our Software Craftsmanship Calendar 2016 on Kickstarter.

Comments