Scalable Human Blog

To start, in object-oriented programming, there is a helpful acronym used within software development named SOLID. Whereby, this was created to define five simple design principles. The goals of the principles, are to achieve more understandable, maintainable and extendable software where designs are understandable.

In addition, to give credit the origin of this acronym was from the famous software engineer and instructor Robert C. Martin, whom has written multitude of best-selling software design and methodology books within the field of software engineering.

What does SOLID stand for?

• Single Responsibility Principle
  • Class should only have one reason to change
• Open-closed Principle
  • Open for extension, closed for modification
• Liskov Substitution Principle
  • Design by contract
• Interface Segregation Principle
  • Many client specifics interfaces are better that one general purpose interface
• Dependency Inversion Principle
  • Depend upon abstraction, not concretions

[S] Single Responsibility Principle

“A class should have only one reason to change”

Martin Fowler

❌ Consider a Rectangle Class…

There are problems with this design…

• Rectangle class is immobile
• You are forced to use its additional dependencies when you may just want one thing!

🤔 Consider this design

Now to question…

• Do these methods make sense together?

✅ Solution

Two Interfaces…

⚠️ Do we need to do this all the time?

• Will parts of your class change when others do not?
  • ✅ If yes – This type of solution is recommend!
  • ❌ If no – This solution may not be required
    • Beware of adding unwanted complexity

[O] Open-closed Principle

Closed for modification and open to extension.

❌ Bad example

We keep editing the method for new changes.

✅ Good Example

🟡 Bonus principle: Illustration above shows the inheritance principle of favouring composition over inheritance.

To note, with this design it should be quite easy to add different TV providers.

[L] Liskov Substitution Principle

You should always be able to substitute subtypes for their base classes.

This can be seen as ensuring a class is behaving as it is intended.

How not to violate this principle?

Design by contract

This technique ensures that the classes design is not breached by determining these key checks:

• Pre-conditions
• Post-conditions
• Variants

Why is this useful?

Testing

These particular contractual conditions will help develop code that is easier to test, therefore creating more robust solutions.

[I] Interface Segregation Principle

Cohesion

How strong are the relationships between an interface’s methods?

❌ Example of low cohesion

Methods are not that similar and serve different purposes.

✅ Example of high cohesion

Methods are related there respective classes.

Maybe we need a machine that requires everything!

[D] Dependency Inversion Principle

High-level modules should not depend on low-level modules.

❌ Bad Example

Low level components are tied to high level components:

✅ Good Example

Both high level and low level should depend on abstraction:

📚 Further Reading & Related Topics

If you’re interested in software design principles and architecture, you might also find the following articles helpful:

• Clean Architecture Book Review: Software Structure and Design Explained – Gain deeper insights into how to practically apply SOLID principles through well-structured software architecture.

• Refactoring: Enhancing Code Design for Optimal Performance – Discover how refactoring aligns closely with SOLID principles, providing strategies for gradually improving the maintainability of your codebase.

These articles will help reinforce and expand your knowledge about writing maintainable, clean, and scalable software.