Solid Principles - Object Oriented Design

Which are the 5 SOLID Principles?

The SOLID principles are used to improve code reusability while maintaining a clean software architecture. SOLID principle were originally defined by Robert C. Martin and they stablish the base for writing clean object-oriented applications. There 5 SOLID principles:

Single Responsibility Principle

Each class on a system should handle a specific business logic and not have multiple responsibilities. Classes become easier to understand and maintain as they don’t mix concerns.

It is importatn to avoid declaring methods that change for different reasons on the same class. As an example: Reporting, calculation, database storage should be placed on different classes.

Open / Closed Principle

Objects or entities should be open for extension, but closed for modification. This principle ensures behaviour changes will not modify the original class. When classes are too tied together their reusability becomes impossible due to their coupled dependency.

If this principle is applied correctly, adding new features on an application implies writing new code without impacting the old code. Failure to apply this principle lead to rigid applications. Classes and modules need to be recompiled due to their internal dependencies when a changes occur.

Liskov Substitute Principle

A principle ensuring that when a superclass gets extended by a subclass, all instances of the superclass type should be able to change its type to match the subclass without braking the application.

This forces a cleaner code by having subclasses behaving the same way as their superclass. In order to apply this principle, an overridden method in a subclass should accept the same input parameters and return the same data type.

Similarly, internal properties of a derived class must match declaration types of its superclass.

Interface Segregation Principle

This principle ensures interfaces on our system are consistent. Though it might sound obvious, when new requirements are added to a system is easy to just add them on existing interfaces. But that is not a best practice. A client should not be forced to depend on interfaces they do not use.

Changes and addition of new methods to interfaces should be consistent with existing business logic. New requirements should not add unrelated functionality. A new interface should be created if that is the case.

Failure to comply with this principle leads to a system full of dependencies. Interfaces become reused by different objects handling different business logic.

Dependency Inversion Principle

Used for decoupling dependencies between modules and its classes. Reusability can be accomplished when high-level modules are not affected by their low-level modules.

Both levels should be dependent on abstractions. Abstraction can be obtained by coding towards interfaces instead of having a high-level module depend on a low-level module directly.

References

• https://www.youtube.com/watch?v=zHiWqnTWsn4
• https://stackify.com/solid-design-liskov-substitution-principle