, , ,

Object Oriented Analysis and Design(OOAD), that is, design principles represent a set of guidelines that helps us to avoid having a bad design.

Let’s discuss some important issues. We can call it SOLID principles (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion).

Single Responsibility Principle
A class should have only one reason to change.

In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it.

Open Close Principle(OCP)
Software entities like classes, modules and functions should be open for extension but closed for modifications.

OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don’t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you’ll prefer to extend it without changing the code that was already written .

Liskov’s Substitution Principle(LSP)
Derived types must be completely substitutable for their base types.

This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.

Ostrich is a Bird (definitely it is!) and hence it inherits the Bird class. Now, can it fly? No! Here, the design violates the LSP.

Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they don’t use.

This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?

Dependency Inversion Principle
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.

Suppose, for some reason Printer should be used in a PC. Then we need a connection port. So, PC and Printer both should have same connection port option. If we need to use Camera in a PC, it will be same. that is the dependency.
If we use abstraction layer, It is so easy. That is USB port.