SOLID Principles Applied to Life

A man trying to cross the street, kudos to the photographer, Desmond Leung.

I'm not sure if you do this, but in my case, whenever I face a real-life issue, I tend to ask myself what solution or design pattern can solve it. I know, it sounds ridiculous, and you're probably right. But it turns out I have found some valuable insights by thinking that way. So, I'm sharing some with you, inspired by the SOLID principles.

SOLID Principles

Before we start, we should list them:

• S — Single Responsibility Principle
• O — Open/Closed Principle
• L — Liskov Substitution Principle
• I — Interface Segregation
• D — Dependency Inversion

Why do we use them? What do they represent?

Well, they're a set of design principles and good practices that help developers write better code, but most importantly, FLEXIBLE AND MAINTAINABLE CODE.

This is the main reason why I think they can be applied to life.

Let me elaborate on that:

S — Single Responsibility Principle

Every function has only one task to do, and it should do it well!

Something that I find curious about life is that every moment we're getting hit by issues. It doesn't matter if they're big or small; we tend to try to solve them all at once. This is where the trap lies! Computers are better than us, filthy humans, at solving MANY problems IN PARALLEL, so why do we try to solve all our problems at once? Break the solution piece by piece, define each piece well, and then KNOW YOUR ROLE AND PLAY IT.

O — Open/Closed Principle

Open for extension, but closed to modification.
This is a tricky one, and it might even seem to contradict the previous one. But, in fact, it does not:

Single Responsibility Principle is about function SCOPE.
Open/Closed Principle is about function STRUCTURE.

Jack of all trades, master of none is not applicable when your decisions are complementary:

I want to learn how to play the guitar, I do code, I like to cook, I want to be fit, and read more books:

• Go for it, practice your guitar.
• Do you code, but want to practice guitar? -> Code something that might be useful for your guitar practice; maybe a metronome or a chord finder.
• Do you like to cook and go to the gym? -> Look for recipes and meal-prep for your week.
• Do you want to be fit and read more books? -> Hit the gym, prepare your phone with some audiobooks, and continue reading when you get home.

Sounds like a lot of work, doesn't it? It is!
Contrary to what we have been taught, knowing a lot of things is not bad when you can integrate them.

Be open to expanding your skills, and remember to stay closed to modifying your core, your essence, your values, your beliefs, and your principles.

You can always REFACTOR your life, but keep in mind that this takes time. And TIME is the only resource that we can't get back, so be careful with it and use it wisely.

L — Liskov Substitution Principle

"Objects of a superclass should be replaceable with objects of its subclasses without breaking the application."

I swear, this one is easy to understand after an example, bear with me:

"Your dependencies should rely on anything that meets the requirement.
They shouldn't depend on specific instances of things."

i.e.: I want to be fit, so I need to go to the gym, but I don't have time to go to the gym, so I can do home workouts, or maybe I can do some outdoor activities like running, or maybe I can do some sports with my friends.
Everything mentioned meets the requirement of being fit, so I can substitute one for another without breaking my goal.

You can take this principle to a more "abstract" and "philosophical" level, and apply it to your income, necessities, relationships, etc.

I — Interface Segregation

"A class should never be forced to implement methods that it doesn't use."

Have you ever had that feeling of playing too many roles for a simple situation?
If so, you probably were!

Look, we tend to put 100% into everything we do, and that's great, don't get me wrong. But this is completely exhausting.

So, what I suggest is to take a step back and ask yourself: "What's the minimal set of requirements to comply with this situation?"
Save yourself from burnout and the stress of trying to be perfect at everything, and just be "perfect" for the situation.

D — Dependency Inversion

"High-level modules/classes should not depend directly on low-level modules/classes."

This is the last one, and the most abstract one. It relies on the Liskov Substitution Principle and Interface Segregation Principle in a certain way.
It's all about removing coupling, which we can translate to life as being RESILIENT and ADAPTABLE.

You'll see, good systems don't rely on a specific dependency. They set the rules and requirements to be met, so anyone can be part of them without breaking them.
Let's set an example:

A good payment system doesn't depend on Bank_A.class. It depends on a payment method, and as long as the payment method meets the requirements, it can be used without breaking the system.
So, you can have Bank_B.class, Bank_C.class, or even a crypto payment method. As long as they meet the requirements, they can be used without breaking the system.
If the system breaks or needs to be modified to add a new payment method, then we say it's coupled, and that's bad.
The best systems are those that can change over time with zero downtime.

How can we apply this to life?
Well, we can be resilient and adaptable to change, of course, but set standards, rules, and requirements to be met, so anyone can be part of our life without breaking it.
Set boundaries, and be open to new people, new experiences, new ideas, as long as they meet the requirements of being respectful, kind, and supportive.

Conclusion

I know this might sound a bit crazy, but I hope you can take something from this. It's incredible how much you can learn from something that seems so specific to a field, but can be applied to life in general. I'm starting to think that engineering is not just about building things; it's about fighting back against entropy.