April 17, 2022 –

SOLID Design Principles by uncle Bob explained

There are many ways to reduce the dependency on one code section, but what if we want or need that change? As an introduction to SOLID principles, let’s start with a quick review of what it is as a concept.

SOLID are design patterns to make it easier for software engineers to avoid issues and build adaptive, effective, and agile software.

SOLID is an acronym coined by Robert C. Martin that represents five basic principles of object-oriented programming. Following these principles eliminates bad designs, avoids refactoring, and builds more efficient and maintainable code.

Who is Robert C. Martin?

Robert C. Martin has worked in software for more than 40 years. He has been a programmer for more than 35 years and has worked on various software projects. He is the author of books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, and C++ Programming, among other topics.

Currently, he is one of the world’s best authorities on Agile software development and a recurring speaker at international gatherings and trade shows.

Why do they call him uncle bob?

The most popular reason is that it’s a play on R.C. Martin’s initials. Uncle Bob is also a nickname for someone generous with their knowledge and experience, which Robert C. Martin is within the software development community.

He is the Uncle Bob in Clean Code: A Handbook of Agile Software Craftsmanship.

This book is a great starting point for anyone who wants to learn more about writing high-quality code.

He’s a seasoned technology writer and former editor of the C++ Report. He now contributes a Craftsman column monthly for Software Development magazine, the CEO and president of his own company, Object Mentor Incorporated.

Object Mentor specializes in object-oriented technologies and Agile/XP development methodologies and provides consulting, training, mentoring, and various development services.

The five SOLID guidelines for software application design:

S -Single Responsibility Principle.

"A class should have one, and only one, reason to change." The Single Responsibility Principle is the most fundamental principle of SOLID, it is simple to explain but the most difficult to follow in practice. "Gather together the things that change for the same reasons. Separate those things that change for different reasons", i.e., "Gather together the things that change for the same reasons. Separate those things that change for different reasons". This principle establishes that a component or class must have a single, simple and concrete responsibility, which simplifies the code by avoiding the existence of classes that fulfill multiple functions, which are difficult to memorize and often mean a waste of time looking for which part of the code does which function.

O -Open/Closed Principle

"You should be able to extend a class's behavior without modifying it." The second SOLID principle, formulated by Bertrand Meyer in 1988 in his book, "Object-Oriented Software Construction," says: "You should be able to extend a classes behavior without modifying it." In other words: the classes you use should be open to being extended and closed to being modified. It's essential to consider the Open/Closed Principle (OCP) when developing classes, libraries, or frameworks.

“Object-Oriented Software Construction,”

L: Liskov substitution principle

"Derived classes must be substitutable for their base classes." That means that objects must be able to be replaced by instances of their subtypes without altering the correct functioning of the system. In other words: if we use a specific class in a program, we should be able to use any of its subclasses without interfering with the program's functionality. According to Robert C. Martin, violating the Liskov Substitution Principle (LSP) also implies violating the Open/Closed principle. This principle states that a subclass can be substituted by its superclass. We can make a subclass called Auto that derives from the superclass Vehicle. If by using the superclass, the program fails, the principle is not satisfied.

I: Interface segregation principle

"Make fine-grained interfaces that are client-specific." It's better to have many interfaces that define few methods than numerous interfaces that must implement many functions, according to the Interface Segregation Principle (ISP). Each class must include the interfaces it will use. Adding new features or changing existing ones will be easier in this way. According to Robert C. Martin, violating the Liskov Substitution Principle (LSP) also implies violating the Open/Closed principle. This principle states that a subclass can be substituted by its superclass. We can make a subclass called Auto that derives from the superclass Vehicle. If by using the superclass, the program fails, the principle is not satisfied.

D: Dependency Inversion Principle

"Depend on abstractions, not on concretions." DIP reduces dependencies between modules in the code, i.e., to achieve low coupling of classes. The Dependency Inversion Principle states that high-level modules should not depend on low-level modules, and they must be dependent on abstractions in both situations. High level refers to operations whose nature is broader or encompasses a more general context, and low level is more specific individual components.

Software engineers can make their designs more robust and accessible by following the SOLID principles. These five factors work together to avoid problems during construction or maintenance phases when changes need to occur due to an ever-changing environment, ultimately leading to a more effective end product created via adaptivity.

Why do we need these principles?

By following these principles, developers can break down their applications into smaller, more manageable pieces, making it easier to track down and fix problems and make changes to the codebase without causing unintended consequences.

How do we follow the SOLID principles?

There is no one-size-fits-all answer to this question, as the SOLID principles need tailoring to specific codebase and project requirements.

However, some tips for following the SOLID principles include:

• Breaking down the application into smaller classes and modules

• Keeping methods short and simple

• Defining interfaces for classes, rather than forcing them to implement too many methods

• Ensuring that high-level modules depend on abstractions, not on low-level modules or details.

The SOLID principles are guidelines for software application design that help achieve high quality, well-organized and maintainable code. By following these principles, developers can create code that is easier to understand and more resistant to change.

The benefits of using SOLID design principles are clear, with increased maintainability and scalability leading to better systems. Engineers worldwide can benefit from this method because it’s used in many industries nowadays!

Ver esta publicación en Instagram

Una publicación compartida de DNAMIC (@dnamicai)

Share content

Clutch Top 1000 companies badge over a black background

From bootstrapped startup to Nearshoring Powerhouse: DNAMIC ranks among the top 1000 business service providers on Clutch.

A group f business people working together

How to Get Through the Outsourcing Maze: A Guide for CIOs and CTOs