SOLID is Fragile

Companies that want to remain relevant must be able to keep up with customer demand for new features. Thus, the need for agility requires that the software on which the company depends must be high performing and easy to maintain.

SOLID represents a set of principles and best practices to help developers ensure their code quickly adapts to changing requirements.

With so many people working on a project and the complexity of the system, maintenance can be a challenge.

This guide provides an overview of SOLID, discussing each principle and giving you details on how to spot issues that could be addressed following these methods.

What is SOLID?

SOLID is a set of design principles for object-oriented software development. More than that, it is a framework that outlines the ideal design approach. However, as we’ll see there are some challenges to this approach that have some questioning its usefulness.

The term SOLID is represented as a mnemonic that represents each design principle. The below definition comes from the book:

Refactoring: Improving the Design of Existing Code by Martin Fowler, with Kent Beck

Single Responsibility Principle (SRP): The Single Responsibility Principle (SRP) states that each class should have one purpose. Said another way, there should never be more than one reason for a class to change.

Open/Closed Principle (OCP): With this principle, code should be open for extension but closed for modification.

Liskov Substitution Principle (LSP): The Liskov Substitution Principle states "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program".

Interface Segregation Principle (ISP): "many client-specific interfaces are better than one general-purpose interface."

Dependency Inversion Principle (DIP): one should "Depend upon Abstractions. Do not depend upon concretions."

What Problems Does SOLID Address?

Before we move too far into the discussion, let’s discuss why SOLID came about and the problems it was intended to solve.

SOLID helps prevent issues that would impact code quality.

It specifically addresses:

Rigidity: This happens when the cost of making a single change is very high, for example, if a simple change takes many hours to implement.

Fragility: In this scenario, small changes in one module causes bugs in other modules, even if the modules are unrelated.

Immobility:The software is considered immobile when the components can’t be reused in other systems.

Viscosity: A system is viscous when adding one feature requires dealing with multiple aspects of the application to make the change.

Benefits of SOLID

That said, we can see that there are many challenges that developers face when designing a system. SOLID is a design pattern that emerged as a way to guide developers in writing code that is:

• Clean: Follows coding standards for things such as naming and syntax
• Maintainable: Manageable in that making changes isn’t complicated or causes further issues
• Scalable: Easy to refactor or change code.
• Redundancy: Free of unnecessary duplication in the code
• Testable: Can be easily unit tested.
• Readable: Easy to read and comprehend
• Independent: Few dependencies
• Reusable: Can be reused in other parts of the code

Where Did Things Go Wrong?

When starting a project, it's hard to predict the future. We can only take our best as to what we’ll need. So in an attempt to come up with a “good design” developers try to follow every principle with little regard for future consequences.

This attempt to predict the future can lead to complex designs driven only by “what we think we need” for a future that may never materialize.

As such, developers end up writing code for tons of features that may never be needed.

In addition to the above, SOLID has gained some criticism in the developer community.

Some say that it is too idealistic for real-world application. For example, legacy systems and monoliths are complex systems that sometimes don’t refactor well.

Attempting to do so using SOLID can be an exercise in frustration that most developers don’t enjoy.

It is too time-consuming. They would rather do what is necessary to support those applications and save SOLID for systems that are more fitting to the framework.

So with all of that said, what’s the solution?

Simplicity: The Way Forward

SOLID was never meant to be the sole source of truth for designing software. It was intended to be a guide to writing code that accomplished a specific purpose without causing a headache down the line.

That said, a better approach is to start with a simple design and only refactor as the need arises. The goal is to let the emerging complexity drive the design. At that point, you can refactor using SOLID as a framework to build maintainable code.

Perhaps an even better approach is to start with the Four Rules of Simple Design as a guide.

The rules state that all code should:

How Adservio Can Help

Building reliable and maintainable software requires teams to follow a predefined set of standards.

Adservio’s main goal is to help companies embrace best practices in delivering quality code with the capability to scale and be resilient to adapting the future changes.

Reach out to us to see how we’ve partnered with our clients to achieve quality software.