Software Design Principles

Connect with

What is design principle? it is basically a set of guidline which solve non-functional requirement or functional requirement.
According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:

  • Rigidity: it is hard to change because every change affects too many other parts of the system.
  • Fragility: when you make a change, unexpected parts of the system break.
  • Immobility: Immobility is the inability to reuse software from other projects or from parts of the same project.

1. S.O.L.I.D. Design principles

SOLID is an acronym for the first 5 principles of object-oriented design (OOD) by Robert C. Martin , popularly know as Uncle Bob.

1.1 S.O.L.I.D Stands for?

These are pretty simple to grasp.

  1. S – Single Responsiblity Principle (SRP).
  2. O – Open Closed principle (OCP).
  3. L – Liskov substitution principle (LSP).
  4. I – Interface segregation principle (ISP)
  5. D – Dependency Inversion Principle (DIP)

1.2 One liner description

[table “” not found /]

2. Single Responsibility Principle (SRP)

A class should have one and only one reason to change, meaning that a class should have only one job.
Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. The reason it is important to keep a class focused on a single concern is that it makes the class more robust. for example, there is RDAO class

For example, consider a module that process and prints/display a report. Imagine such a module can be changed for two reasons. First, the content of the report could change. Second, the format of the report could change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules.

Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.

What is a Responsibility?

3. Open Closed principle (OCP)

Software entities like classes, modules and functions should be open for extension but closed for modifications.

A class is closed, since it may be compiled, stored in a library, base lined, and used by client classes. But it is also open, since any new class may use it as parent, adding new features. When a descendant class is defined, there is no need to change the original or to disturb its clients

For more details go Wiki page.

4. Liskov substitution principle (LSP)

Derived types must be completely substitutable for their base types
Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S.

Liskov’s Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy.

for more details go to Wiki page.

5. Interface segregation principle

Clients should not be forced to depend upon interfaces that they don’t use.
When we have non-cohesive interfaces, the ISP guides us to create multiple, smaller, cohesive interfaces. Smaller interfaces are easier to implement, improving flexibility and the possibility of reuse. As fewer classes share interfaces, the number of changes that are required in response to an interface modification is lowered. This increases robustness.

As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.

The ISP was first used and formulated by Robert C. Martin while consulting for Xerox

6. Dependency Inversion Principle (DI)

  • High-level modules should not depend on low-level modules. Both should depend on abstractions.
  • Abstractions should not depend on details. Details should depend on abstractions.

Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.

Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework …) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook (a property, parameter …) and an external module controlling the dependencies will inject the reference to the second one.

7. Some important design point to remember apart from S.O.L.I.D. principles

  • Favour Composition over inheritance: Composition gives you a lot more flexibility, encapsulate a familty of algorithms into your own set of classes, also let you change behaviour at runtime. HAS-A can be better than IS-A.
  • Program to an interface , not an implementation::
    for example use

    List list = new ArrayList();

    not use ArrayList list = new ArrayList();

  • Identify the aspects of your application that vary and separate them from what stays the same: take what varies and “encapsulate” it so it won’t affect the rest of your code.
  • Pattern shows you how to build systems with good OO design qualities.
  • Pattern are not invented , they are discovered.

8. References


Connect with

Leave a Reply

Your email address will not be published. Required fields are marked *