Category: software design

SOLID OBJECT ORIENTED DESIGN PRINCIPLES

Today I did a presentation to explain the SOLID Design Principles for software development. SOLID principles have been around for a couple of decades but more than often they are not applied in our daily development either because of a rush to get things done without using best practices, lack of knowledge, not understanding the importance of it or all of the above.

“It is not the beauty of a building you should look at; its the construction of the foundation that will stand the test of time.”
– David Allan Coe

My goal of this presentation was to keep it simple so even a junior level developer understands the concepts and importance of building applications using SOLID principles. You don’t need to be a software architect to understand and apply these principle in your coding life. There are a lot of articles on the internet which explain SOLID principles (or at least attempt to) along with sample code but a lot of them only make it that much more confusing.

I hope these notes & sample code will help you understand these principles without investing hours of your time trying to grasp these simple but extremely powerful concepts in software development.

Let’s begin with the end in mind. To build any stable, extensible and maintainable software application our main goal is to have low coupling (degree of interdependence between software modules) and high cohesion (degree to which the elements of a module belong together). Let’s see if SOLID can come to the rescue.

Advantages of SOLID principles:

Principled way of managing dependencies especially in a large application

Loose coupling (degree of interdependence between software modules)

More cohesion (degree to which the elements of a module belong together)

Code is more reusable, robust, flexible, testable and maintainable

Let’s get into each principle one by one.

Single-responsibility principle (SRP)

Formal Definition: A class should have one and only one reason to change (single responsibility).

Simple Definition: Do not burden one class with too many responsibilities.

Advantages: Increase cohesion, low coupling, reduced complexity

Open-closed principle (OCP)

Formal Definition: Entities (classes, functions etc.) should be open for extension but closed for modifications

Simple Definition: You should be able to extend a class’s behavior, without modifying it.

Liskov substitution principle (LSP)

Formal Definition: Objects in a program should be replaceable with instances of their sub-types without altering the correctness of that program.

Simple Definition: Objects of the derived class must behave in a manner consistent with the promises made in the base class’ contract.

My definition: All derived classes should be exact sub-types of the base classNOT kind of sub-types.

Advantages: Code re-usability, reduced coupling and less chance of introducing bugs in the existing application.

Interface segregation principle (ISP)

Formal Definition: Many client-specific interfaces are better than one general purpose interface.

Simple Definition: Clients should not be forced to implement interfaces they do not use.

My definition: Break down a large class into smaller manageable interfaces

Advantages: Increased cohesion, more extensible and robust.

Dependency Inversion Principle (DIP)

Formal Definition: Entities must depend on abstractions not on concretions.”

Simple Definition: High level module must not depend on the low level module, but they should depend on abstractions.

My definition: Anytime I new up a class it’s time to look at DIP

Advantages: Loose coupling.

Bottom Line:

SOLID principles are not rules but just guidelines. These guidelines will help us build more robust, extensible, testable and maintainable applications. If you understand the concepts you will also find out it takes care of:

Though SOLID can help you solve most of the code smells and issues we face in any large applications it should be used with common sense and individual client’s needs in mind. Just because you can doesn’t mean you should 🙂