Object-oriented design principles
Now, let's talk about another set of concepts that are going to be crucial for us. These are nothing but the object-oriented design principles that will act as a toolbox for us while learning design patterns in detail.
The open/close principle
The open/close principle states that classes or objects and methods should be open for extension but closed for modifications.
What this means in simple language is, when you develop your software application, make sure that you write your classes or modules in a generic way so that whenever you feel the need to extend the behavior of the class or object, then you shouldn't have to change the class itself. Rather, a simple extension of the class should help you build the new behavior.
For example, the open/close principle is manifested in a case where a user has to create a class implementation by extending the abstract base class to implement the required behavior instead of changing the abstract class.
Advantages of this design principle are as follows:
- Existing classes are not changed and hence the chances of regression are less
- It also helps maintain backward compatibility for the previous code
The inversion of control principle
The inversion of control principle states that high-level modules shouldn't be dependent on low-level modules; they should both be dependent on abstractions. Details should depend on abstractions and not the other way round.
This principle suggests that any two modules shouldn't be dependent on each other in a tight way. In fact, the base module and dependent module should be decoupled with an abstraction layer in between.
This principle also suggests that the details of your class should represent the abstractions. In some cases, the philosophy gets inverted and implementation details itself decide the abstraction, which should be avoided.
Advantages of the inversion of control principle are as follows:
- The tight coupling of modules is no more prevalent and hence no complexity/rigidity in the system
- As there is a clear abstraction layer between dependent modules (provided by a hook or parameter), it's easy to deal with dependencies across modules in a better way
The interface segregation principle
As the interface segregation principle states, clients should not be forced to depend on interfaces they don't use.
This principle talks about software developers writing their interfaces well. For instance, it reminds the developers/architects to develop methods that relate to the functionality. If there is any method that is not related to the interface, the class dependent on the interface has to implement it unnecessarily.
For example, a Pizza interface shouldn't have a method called add_chicken(). The Veg Pizza class based on the Pizza interface shouldn't be forced to implement this method.
Advantages of this design principle are as follows:
- It forces developers to write thin interfaces and have methods that are specific to the interface
- It helps you not to populate interfaces by adding unintentional methods
The single responsibility principle
As the single responsibility principle states, a class should have only one reason to change.
This principle says that when we develop classes, it should cater to the given functionality well. If a class is taking care of two functionalities, it is better to split them. It refers to functionality as a reason to change. For example, a class can undergo changes because of the difference in behavior expected from it, but if a class is getting changed for two reasons (basically, changes in two functionalities), then the class should be definitely split.
Advantages of this design principle are as follows:
- Whenever there is a change in one functionality, this particular class needs to change, and nothing else
- Additionally, if a class has multiple functionalities, the dependent classes will have to undergo changes for multiple reasons, which gets avoided
The substitution principle
The substitution principle states that derived classes must be able to completely substitute the base classes.
This principle is pretty straightforward in the sense that it says when application developers write derived classes, they should extend the base classes. It also suggests that the derived class should be as close to the base class as possible so much so that the derived class itself should replace the base class without any code changes.
