Object Oriented Class Design Principles
In this article, I would like to discuss about some of the important Object Oriented Design Principles. I assume, many of us already worked on Object Oriented Languages like C++, Java, C# etc. Hence by knowingly or unknowingly we have used these principles. Let us see them in details here.
Software requirement may keep on changing over period of time. Whatever software we are developing today may not fulfill tomorrow's needs. So ideal software should be designed in such a way that if tomorrow any need to changes it, should be done easily without any nightmare. ie; software must easily maintainable and extensible. How can we create software designs that are stable while keeping change in mind?
Here is what the importance of Object oriented design comes. The heart of Object oriented design is a set of Object Oriented Design Principles and Patterns. Mainly there are categories of design principles.They are
1. Principles of Class design
2. Principles of Package Coupling
3. Principles of Package Cohesion
In this article, I will be focusing on Class design Principles. The following are the important Object Oriented Class Design Principles.
1. The Single Responsibility Principle:
Definition:
THERE SHOULD NOT BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
- Robert C. Martin
As per above definition, a class can have only one responsibility. If you can think a class need to be modified due to different reasons than that class has more than one responsibility. In this case, a better design should be separate the different responsibilities into different classes.
public class Client
{
public void OpenConnection();
public Dataset GetClientDetails();
public void CloseConnection();
}
In the above example, the Client class having 3 methods; first method will establish connection to the database, second method is used to fetch Client data from database and third method will disconnect connection to the database. From functional point of view, using the above class we can achieve the functionality. From design point of view, it is not following Single Responsibility Principle.Here class having multiple responsibility. In the above case, a better design will be as follows by separating
responsibilities into 2 classes.
public class Client
{
public Dataset GetClientDetails();
}
public class ConnectionMangaer
{
public void OpenConnection();
public void CloseConnection();
}
2. The Open Closed Principle:
Definition:
SOFTWARE ENTITIES SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.
- Robert C. Martin and Bertrand Meyer
The above principle asserts 2 points. Software design must be open for extension and closed for modification. At once, it looks like contradictory. How can we extend a software without modify it? What it says is software should be designed in such a way that new features can be added to a class or module without modifying the existing code.
Suppose we are developing software for a private bank and that point of time, that bank is maintaining only 2 kind of accounts: Savings Account and Current Account.
But in future there are chances that other type of account can also come in to picture like recurring deposit account, fixed deposit account etc. So, classes should be designed by keeping change in mind.
For Example:
public abstract class Account
{
public abstract double InterestCalc();
}
public class Savings : Account
{
public override double InterestCalc();
{
}
}
public class Current : Account
{
public override double InterestCalc();
{
}
}
public double InterestCalc(Account[] accnt)
{
double interest = 0;
foreach (var s in accnt)
{
interest += s.InterestCalc();
}
return interest;
}
If tomorrow, a new type of account called RD comes no need to modify the current design. Developer can add a new class as follows and extend the existing functionality.
public class Recurring Deposit : Account
{
public override double InterestCalc();
{
}
}
3. The Liskov Substitution Principle:
Definition:
FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.
- Robert C. Martin and Barbara Liskov
The above principle is named after Barbara Liskov. This principle says while inheritance, there is no need for the base class to aware of the different concrete classes which are derived from it. Also derived class can be used as a substitute for its base class, if it does not change the behavior of base class. ie; If we are deriving class from the base class, we should not modify any of its parent behaviour.
4. The Interface Segregation Principle:
Definition:
CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE.
- Robert C. Martin
The above principle says, a class which extends from an interface should not be forced to use functions which are not related to that class.
We all know when a class inherits from a interface, it must implement all methods of that interface. In any case, if an interface contains a method which not is not related few class inheriting from that interface, then we should split the interface in such a way that it should group only related functionality. So as a developer, we should be always be careful while adding a new methods to an existing interface and for a better design we should follow above principle.
5. The Dependency Inversion Principle:
Definition:
HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS AND ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS.
- Robert C. Martin
This principle says to avoid tight coupling between modules. Consider, if a module or class is dependent on another class and if we change one,we may need to change the other too.In this case, module/class are tightly coupled. We need to apply the concept abstraction where ever applicable while designing classes. By doing this we can achieve loose coupling between modules.ie; less dependency between modules.
The above principles are collectively known as S.O.L.I.D principles. You can see if we apply these principles while designing our classes or modules, we can maintain and extend them easily.