Murphy’s laws and SOLID principles.

The book, titled “Murphy’s Law: Reasons Why Things Go Wrong!”, was issued in 1978 and is a humorous take on Murphy’s Law, which states that “Anything that can go wrong, will go wrong.” The book is not related to software development or programming, but it is a lot of fun about engineering principles in general.

SOLID, Introduced by Robert C. Martin (aka “Uncle Bob”) in the early 2000s, is an acronym representing five principles

∙ The Single Responsibility Principle (SRP)
∙ The Open-Closed Principle (OCP)
∙ The Liskov Substitution Principle (LSP)
∙ The Interface Segregation Principle (ISP)
∙ The Dependency Inversion Principle (DIP)

The SOLID principles are not the only set of guidelines for writing high-quality software. Other principles and practices, such as the DRY (Don’t Repeat Yourself) principle, the KISS (Keep It Simple, Stupid) principle, and Test-Driven Development (TDD), are also widely used by developers to write clean, maintainable code.

That being said, it is possible to find sarcastic comments about SOLID principles from some developers who disagree with the principles or find them too restrictive. However, it is important to remember that OOP engineering principles, such as SOLID, are generally considered best practices in software development, and following them can lead to more maintainable, scalable, and flexible code. Like any set of guidelines or principles, they are not perfect and may not always be applicable to every situation, but they are a useful starting point for writing high-quality software.

Let’s refresh knowledge.

SOLID is an acronym that represents five principles of object-oriented programming. These principles are guidelines that help developers write maintainable, scalable, and flexible software. Here’s a brief explanation of each of the SOLID principles.

Single Responsibility Principle (SRP).

This principle states that a class should have only one reason to change. In other words, a class should have only one responsibility, and it should do it well. This means that a class should have a single focus and should not have too many responsibilities. This helps to make the code more maintainable and easier to understand.

Open-Closed Principle (OCP).

This principle states that a class should be open for extension but closed for modification. This means that we should be able to extend the behavior of a class without modifying its existing code. We can achieve this by using interfaces, abstract classes, and dependency injection.

Liskov Substitution Principle (LSP).

This principle states that a subclass should be able to substitute its superclass without causing any problems in the system. In other words, a subclass should be able to be used wherever its superclass is used without any unexpected behavior. This helps to make the code more reusable and easier to maintain.

Interface Segregation Principle (ISP).

This principle states that a client should not be forced to depend on methods it does not use. In other words, we should not have big interfaces that have many methods that are not used by the client. Instead, we should have smaller interfaces that are focused on a single responsibility.

Dependency Inversion Principle (DIP).

This principle states that high-level modules should not depend on low-level modules. Instead, they should both depend on abstractions. This means that we should use interfaces or abstract classes to decouple the implementation of a module from its dependencies. This helps to make the code more flexible and easier to test.

SOLID principles of object-oriented programming often act like Murphy’s laws for developers. They provide guidance on how to avoid making common mistakes and help developers write better code. But as we all know, Murphy’s law states that “Anything that can go wrong, will go wrong.”

Why developers break SOLID principles?

In summary, developers may break SOLID principles for various reasons asit is not always easy to follow them in every situation. There can be various reasons for that, including:

Lack of Understanding

SOLID principles are not always easy to understand, especially for beginners or developers who have not had a lot of experience with object-oriented programming. Without a clear understanding of the principles, it can be challenging to apply them correctly.

Time Constraints

Developers may have tight deadlines or other time constraints that prevent them from following best practices or taking the time to refactor their code. In such cases, they may prioritize getting the code out quickly over following SOLID principles.

Complexity

Some software systems are inherently complex, and it can be challenging to follow SOLID principles in such systems. In some cases, following SOLID principles may actually increase complexity and make the code harder to maintain.

Business Priorities

Sometimes, developers may have to make trade-offs between following SOLID principles and meeting business requirements or priorities. In such cases, they may choose to break SOLID principles if it helps them deliver the required functionality faster or more efficiently.

Legacy Code

Developers may have to work with legacy code that does not follow SOLID principles. In such cases, it can be challenging to refactor the code to follow SOLID principles without introducing new bugs or breaking existing functionality.

Anything that can go wrong, will go wrong.

So, SOLID principles are there to remind us of what can happen if we don’t follow them. For example:

Single Responsibility Principle:

If you try to do everything, you’ll end up doing nothing.

Open-Closed Principle:

The more you change, the more things break.

Liskov Substitution Principle:

Assumptions can be deadly. Don’t assume that a subclass will behave like its superclass.

Interface Segregation Principle:

Bigger is not always better. Keep your interfaces small and focused.

Dependency Inversion Principle:

Don’t put all your eggs in one basket. Decouple your code to make it more flexible.

However, it is important to understand the benefits of SOLID principles and strive to follow them wherever possible to ensure that the software is maintainable, scalable, and flexible over time.

While SOLID principles have become popular in object-oriented programming, they are not without their criticisms. Some developers argue that following SOLID principles too strictly can lead to overly complex code or that the principles do not apply to every situation. Others argue that SOLID principles are too focused on object-oriented programming and do not address other important aspects of software development, such as performance or security.

In the end, SOLID principles and Murphy’s laws are reminders that programming is not an exact science, and things can go wrong. But by following good principles and best practices, we can minimize the chances of things going wrong and make our code more reliable and maintainable. And if things do go wrong, at least we can say “I followed the principles, but Murphy’s law got me again!” with a smile on our face.