publication

Solid Principles - Object Oriented Design

Miquel Canal

Thursday 7, January 2021
  • Software Architecture
  • Software Patterns
  • Programming Best Practices

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

The 12-Factor methodology

The 12-Factor methodology

The twelve-factor app is a methodology used to build software-as-a-service apps that are easy to scale up without significant changes to tooling or architecture.

Best Practices in Express JS (Node.js)

Best Practices in Express JS (Node.js)

Fast, unopinionated, minimalist web framework for Node.js. The post covers best practices for developing Node.js applications on top of the Express JS web framework.

Hexagonal Architecture

Hexagonal Architecture

How to implemenet Hexagonal Architecture design pattern in software applications. Review of concepts to build software apps that are easy to maintain and scale.

This site uses cookies to ensure a great experience. By continue navigating through the site you accept the storage of these cookies.