

























SOLID principles are acronym for five design principle derived by Uncle Bob (Robert C. Martin) to make software design more understandable, flexible and maintainable. Basically, they applied on Object Oriented design and form a core philosophy for Agile methodology.

I read one of his (Uncle Bob) book i.e., Clean code before one year and I got definition for code quality there, i.e.,

WTF/minute.

Means, code quality is inversely proportional to WTF/Minute.

Now coming to SOLID, So SOLID contains 5 different principles that is used in Object Oriented Design.

If you want to learn PHP, buy a great deal on it Globally and in India

# Single Responsibility Principle

The principle states —

A class should have one and only one reason to change,

A class should have only one job. Means, if we have two reason to change for a class, we have to split the functionality in two classes. Each class must handle single responsibility only and in future if we need to make one change, we can change in the class which handles it. Other classes will remain untouched.

For Example: let’s assume we are handling session management using PHP.

Source code <?php interface ISession { public function setSession ( $sesstionVar ) ; public function getSession ( ) ; } class SessionClass implements ISession { public function setSession ( $sesstionVar ) { // set session code }; public function getSession ( ) { // get session code}; } ?>

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of responsibilities is done only when the full picture of how the application should work is well understand.

# Open Close Principle

The principle states —

Objects or entities should be open for extension, but closed for modification.

This means that class should be extendable without modification into it. The Open/Close principle states that design and code should be done in a way that new functionalities can be added using new class, keeping the current code unchanged as much as possible or with minimum code change.

There are many design patterns that help us to extend code without changing it. For instance the Decorator pattern help us to follow Open Close principle. Also the Factory Method or the Observer pattern might be used to design an application easy to change with minimum changes in the existing code.

# Liskov Substitution Principle

The principle states —

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

From Web Archive

Liskov’s principle imposes some standard requirements on signatures that have been adopted in newer object-oriented programming languages

Contravariance of method arguments in the subtype.

Covariance of return types in the subtype.

No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype.

In addition to the signature requirements, the subtype must meet a number of behavioral conditions. These are detailed in a terminology resembling that of design by contract methodology, leading to some restrictions on how contracts can interact with inheritance:

Preconditions cannot be strengthened in a subtype.

Postconditions cannot be weakened in a subtype.

Invariants of the supertype must be preserved in a subtype.

Let’s take a php example here. Sometime we use service call i.e., ‘->call()’ to call a method e.g.,

This is a complete breach of LSP. Because the call method forces the mention of class name in each method call. At the time of object assignment to $service variable, it should have been decided which class object’s reference it will contain.

# Interface Segregation Principle

ISP states —

No client should be forced to depend on methods it does not use.

ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Let’s take an example of different shapes, Suppose we implement an interface that implements method to calculate Area and Volume. Now if we are using that interface for a Ball, area and volume both can be calculated But in case of square, volume can’t be used. So in that case We should create two interfaces one implement Area and Another for Volume. Now, in case of Ball both interfaces can be implemented and in case of square use interface that has area calculation.

In other words, you should not have to implement methods that you don’t use. Enforcing ISP gives you low coupling, and high cohesion.

# Dependency Inversion Principle

DIP states —

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.

The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction should be thought as an abstract interaction between them. This not only has implications on the design of the high-level module, but also on the low-level one: the low-level one should be designed with the interaction in mind and it may be necessary to change its usage interface.

In many cases, thinking about the interaction in itself as an abstract concept allows the coupling of the components to be reduced without introducing additional coding patterns, allowing only a lighter and less implementation dependent interaction schema.

That’s all about SOLID principles. If you have questions or have any suggestion, you are welcome with suggestions/comments.

Share this: Tweet





Like this: Like Loading...