Design Principles

Sumeet Sumeet Follow Oct 12, 2018 · 2 mins read
Design Principles
Share this

Below are some object oriented design principles which I usually tend to follow in my day to day development tasks. I have learnt a great deal of design principles and patterns from, and below is an attempt to recollect whatever I had learnt and have been implementing since quite some time.

  • Open Close Principle: As per this principle, the codebase/classes should be open for extensions but closed for modifications. A software should be built in such a way that if a change is required, it should require minimum efforts without jeopardizing the entire codebase into a series of changes and breaks. Of course an important one to follow, who likes the surprise technical dept anyway.

  • Dependency Inversion Principle: It talks about keeping your code and class hierarchy flexible. Ideally, low level classes and high level classes should not depend on each other directly. If something changes in low level class, then the complex logic built in high level class will be impacted and vice versa. It is always a good idea to create a layer of abstraction between these classes so that both high level and low level classes depend on this abstraction. In the case of java, implementing such dependencies via interfaces should be done. Let the interface/abstraction take care of the details in such a way that if anything changes on any side, there is only one place to take care of the dependencies.

  • Interface Segregation Principle: When dealing with ‘similar’ objects, it should be considered that each type of object has a separate interface. This takes us into the concept of polluted interfaces. When we say similar objects, it means that not all objects would use all the methods defined in a common/fat interface. If we think about it in a larger code base this increases complexity. Thus as a design principle, it should be made sure that every type of object has its own interface.

  • Single Responsibility Principle: It simply means, one class should have only one reason to change. Basically, one class should do only one thing and should do it right.

  • Liskov’s Substitution Principle: My favourite. It states that if a code/function is depending on an instance of a base class, then it should be completely fine if the instance of the base class is substituted by instance of any derived class. Classic.

I shall keep posting more stuff about these principles and patterns as this is one of my areas of interest.

Join Newsletter
Get the latest news right in your inbox!
Written by Sumeet Follow
Hi, I am Sumeet, and I believe the world belongs to the doers. Here, I publish my technical tinkering experiences. I hope you like it!