Understanding Software Design Principles

Understanding Software Design Principles

When any developer start writing code of any feature/module, the best practice is to try to formulate the high level Interfaces/classes and methods on a white paper / board and try to explain it to yourself why you have decided to have these methods and their parameters and the names of methods? what are the responsibilities of each method etc.

Once you convince yourself, it is very easy to convince others as you have the rational behind each and everything you defined. This is what is called “Designing”.  Designing doesn’t mean you have to draw the UML diagrams like Class Diagram, Sequence Diagram (I am not advocating you to avoid UML). Perhaps UML is the standard way to define the things, to be able to communicate the common understanding between distributed teams.

To Design your classes and Interfaces better there are many software design principles, very famous one is SOLID (expansion as below). Apart from this there are many principle many developers are not aware of, I am here trying to throw some light on those principle as well.

  • SRP     ( Single Responsibility Principle)
  • OCP    ( Open Close Principle)
  • LSP     ( Liskov Substitution Principle)
  • ISP      ( Interface Segregation Principle)
  • DIP      ( Dependency Inversion Principle)

SOLID principles are explained here, If you would like to have a quick recap.

SKY principles:

SKY is a name given by me,[don’t bother if you don’t like the name] I am just trying to use the word, which make sense.

  • SOC    ( Separation of Concerns )
  • KISS    ( Keep it simple, Stupid )
  • YAGNI ( You aren’t gonna need it )

These three principles are very very useful when you try to apply them in real time. So, lets try to discuss each one of them below in detail and if possible I will give you some example as well.

SoC (Separation of Concerns) :

This term was coined by Edsger W Dijkstra in 70 s, His idea behind this is just keep the separate things separately. You should keep the related things together and non related things separate. Let me put it in different terms, If you have to write a web page write HTML in one place, write CSS in another place and JS in different place. The reason behind doing this is each one has a different concern.

HTML focus on the text you would like to show on the page, here the concern is the what you want to show on your page. CSS focus on the style of the text you want to show like Font, size, color etc. Here the concern is How you are going to display the text of HTML. JS (Java Script) has a completely different concern to manipulate the DOM or Apply client side validations etc.  So, It is very easy if you separate the concerns with your business functionality, however this is a high level abstraction in the hierarchy. This intern brings the Single Responsibility, which you can apply very easily when you have a high level SoC.

If you don’t do SoC in early stages of the application, just imagine the HTML page with inline CSS and the JS written inline too. Can you maintain the code ?Can you read the code ? the answer I can guess is “NO”. So, these are the implications if you don’t do the SoC in the first place.

KISS ( Keep it simple, stupid):

This principle is started with a military systems design of US, they learned the systems should be as simple as possible to be maintained well. This has another meaning “Keep it Short and Simple” also. The idea you can easily get with this is you should design something only when it is needed 100%.

If you are trying to design Layers, I have seen some Architects who does too many Layers, and the reasons behind creating these layers will become absolute when the developers in the team changes. So, all these layers act as deli-gators with only line of code calling the next layer’s method.  This is a pure overhead. That is when you should apply KISS. Lets try to keep this things simple. 🙂

If you really need those layers document the responsibility of each layer correctly and communicate the same to the team. It is always better to keep the design simple, when the team changes we might not have to give a long KT (Knowledge transfers) sessions, when you have a simple design.

YAGNI ( You aren’t gonna need it ):

This is a awesome principle according to me, and very similar to KISS principle.  This principle forces you to think twice before you add any new behaviors to your objects. Do you really need this to the object ? Once you are satisfied with this answer, you could add them to that class. Usually when we ask these questions to our self, we might get the answer “May be this is not required here” or “We already have a similar method in another class” etc.

If we could implement this, we could save the development time, testing time etc, by NOT developing something which is not required. We won’t be doing over engineering the system because of this.

Hope this helped you, keep applying these principles in daily life

…. Happy reading 🙂

Reference for Design Principles is here.


2 thoughts on “Understanding Software Design Principles

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s