OO Design principles (SOLID overview)- What are they and why we need them

Share

OO Design Principles


W
e write or modify code but offenly neglect some important guidelines which results in a complete bad design. It takes just a few minutes to go through these principles and every time we write code – its a good design.

Object Oriented design principles are the guidelines that helps us to avoid having a bad design. Robert Martin gave these guidelines in his book “Agile software develpment, design patterns and practices”. Martin says, there are mainly five reasons for having a bad design in a software-

1. Rigidity – It is hard to change because every change affects too many other parts of the system.

2. Fragility – When you make a change, unexpected parts of the system break.

3. Immobility – It is hard to reuse in another application because it cannot be disentangled from the current application.

4. Viscosity of Design– For any software requirement or a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e.they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.

5. Viscosity of Environment– Viscosity of environment comes about when the development environment is slow and inefficient. For example, if compile times are very long, engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optiimal from a design point of view.

Directly or indirectly, the root cause of all the above reasons is the improper dependencies among the modules of the software. So, if we properly  manage the dependencies between the modules -we can get over to all of the above causes. These principles popularly known as SOLID would help us in a proper management of all such dependencies – which if we just remember while coding could help us avoid having a bad design.

1. Single Responsibility Principle (SRP)

there should never be more than one reason for a class to change.

2. Open Close principle (OCP)

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

3. Liskov’s Substitution Principle (LSP)

functions that use references to base classes must be able to use objects of derived classes without knowing it.

4. Interface Segregation Principle (ISP)

many client specific interfaces are better than one general purpose interface.

5. Dependency inversion Principle (DIP)

one should “Depend upon Abstractions. Do not depend upon concretions.

In subsequent posts I would be writing about the individual principles with examples.