SOLID - The First 5 Principles of Object Oriented Design

SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin (also known as Uncle Bob).

S - Single-responsability Principle

A class should have one and only one reason to change, meaning that a class should have only one job.

Code without the principle:

The problem with the output method is that the AreaCalculator handles the logic to output the data. Consider a scenario where the output should be converted to another format like JSON. All of the logic would be handled by the AreaCalculator class. This would violate the single-responsibility principle. The AreaCalculator class should only be concerned with the sum of the areas of provided shapes. It should not care whether the user wants JSON or HTML. To solve this we will create a separate class that will handle only the display format of the data from the sum

Code with the principle:

O - Open-Closed Principle

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

Code without principle:

The issue is that every time we have a different type of shape we will need to add more if statements there, to fix that we will make each Shape has their own area method

Code with principle:

L - Liskov Substitution Principle

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

This means that every subclass or derived class should be substitutable for their base or parent class.

When you call the HTML method on the $output2 object, you will get an E_NOTICE error informing you of an array to string conversion.

To fix this, instead of returning an array from the VolumeCalculator class sum method, return $summedData:

The $summedData can be a float, double or integer.

That satisfies the Liskov substitution principle.

PS: To be honest, I think they could show a better example of this principle, I will try to find it in another article later

I - Interface Segregation Principle

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use

This statement says about you putting the type of a parameter of a method being a specific class instead of an interface, this will make it required that everytime we use this method we will need to pass a value that needs all the methods of the class we added in the type, even tought we didn't use all those methods

Using the previous code, now we need to implement volume for three-dimensional shapes like Cuboid and Spheroid, to make that happen we could apply a volume method for our interface ShapeInterface, but this won't be right because flat shapes don't have volume.

To make our code use the principle, we will break those methods in different interfaces so we could apply only on classes that really use them.

To improve even forward we can create a interface for calculate too

D - Dependency Inversion Principle

Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.

Instead of using the class directly, we can use the parent class or even the interface that is more abstract than the class directly. With that we can achieve decoupling.

Code without the principle:

Code with the principle: