Object Oriented Design Principles.

Object Oriented Design Principles

Prerequisites: Aware of object oriented principles like encapsulation,polymorphism and inheritance, how to create classes and objects.
In Software Development, Object Oriented Design follows guidelines and design principles which are applied to classes and objects and hence are used to design the software in such a way that

1.The classes and the code in the software are divided into modules.
2.The code is reusable.
3.The code is flexible.

The most important benefit of designing software using OOD principles is that it can withstand changes to the software in future versions of the software. It is easily extendible and reusable.

In this article we are going to look at some of the most useful and basic principles of Object Oriented Designing.

1. A class should have one and only one responsibility that is the methods in the class should serve a single purpose otherwise the code in that class becomes tightly coupled. You should break down your methods such that each method performs a particular task. That allows re-use of methods, and if a change is required, it can be done by minimal modification of code.

For Example if there is Student class which has two methods one is to Get student details and another is to Get Student Fee payment details. And there are two applications called Student Details which gets all student details and Payment Details which gets all information about the payment made by the students. This violates our OOD Rule as the class is serving 2 different purpose which leads to different problems like if there is a change in the student class for the Student Details application this may lead to a change, compiling and testing of the Payment Details application and Vice Versa that is the reason we need to create the classes based on responsibility.

We should create one class for Student Details which contains the Get student details method and another class for Payment Details which contains the method to get Fee Payment details. We can also separate the classes into 2 dll files which will be completely independent of each other and change in one class does not affect other dll. Thus the classes can be reused and managed centrally.

2. The Classes and methods must be extensible but not be modifiable that means the behavior of the class can be extended and it can behave in different way as the requirements change .

you should abstract the things that are the core concepts of your application, and if abstraction is done well, most likely, it would require no change when the functionality is to be extended because we define the abstract things in the implementations and not in the abstract class. This would allow you to extend the abstract thing and define a new implementation without doing any change in the client code.

3. The third principle says that Subtypes must be substitutable for their base types." Or Subtypes must be substitutable for their base types."
"Inheritance" is usually described as an "is a" relationship. If a "Developer" is a "SoftwareProfessional", then the "Developer" class should inherit the "SoftwareProfessional" class. Such "Is a" relationships are very important in class designs.

For Example: Lets say we have Bird as base class having Fly method. Pigeon is a Bird and it can fly so it can inherit from the Bird class whereas Ostrich is a Bird (definitely it is!) and hence it inherits the Bird class. But ostrich cant fly so this violates the OOD principle. Ostrich should not inherit the Bird class, and there should be a separate class for birds that can't fly and Ostrich should inherit that.

Point to be noted is that the class hierarchies (Inheritance) would be a mess, and if a subclass instance was passed as parameter to methods, strange behavior might occur.

4. Clients should not be forced to depend upon interfaces that they do not use." Interfaces should be developed in a way that it has its own responsibility , it is specific, reusable and easily understood. Similarly, suppose you have some classes and you expose the functionality of the classes using interfaces so that the outside world can know the available functionality of the classes and the client code can be done against interfaces. Now, if the interfaces are too big and have too many exposed methods, it would be confusing to the outside world.

5. "High level modules should not depend upon low level modules. Rather, both should depend upon abstractions." That is we should define abstract methods so that it can be extended if required.