SOLID Part# 1

I'm writing this article as I gone through many of the online tutorials (Video/Text both) on SOLID Principles, but I was still not getting thrilled. In most of the tutorials or learning articles I see they follow a common pattern; they first describe the definition of each principle falls under SOLID and then show some code samples to describe these principles. This is also a most common interview question, in most of the interviews interviewer asks about SOLID and the candidates start with the definition of each principle with some code samples based on what they have learned after going through the same tutorials/online courses and interviewer feels happy that candidate knows about SOLID principle but in reality, they do not, nor they follow.

Well, it's not about the interview, it's not about you know what SOLID is, it's about the SOLID principles.

I continued with my research and finally found my uncle who gave me that thrill I was looking for :)

It's Uncle Bob (Robert Cecil Martin)

Uncle Bob often asked a question, I myself also have the same question "How should I get started with SOLID principles?".

BTW, SOLID principles are not rules, they are not laws, they are not perfect truths.

Ahh, what the hell it is?

Well, everyone in this world knows "An apple a day keeps the doctor away." - This is a good principle, it is also a good advice, but it's not a pure truth, nor is it a rule.

Principles:

• Are mental cubby-holes.
• A name to a concept so that you can talk and reason about that concept.
• A place to hang the feelings we have about good and bad code.
• Attempt to categorize the feelings into concrete advice. In that sense, the principles are a kind of anodyne.

Given some code or design that you feel bad about, you may be able to find a principle that explains that bad feeling and advice you about how to feel better.

• These principles are heuristics.
• They are common-sense solutions to common problems.
• They are common-sense disciplines that can help you stay out of trouble. But like any heuristic, they are empirical in nature.
• They have been observed to work in many cases; but there is no proof that they always work, nor any proof that they should always be followed.

Important points:

• Principle will not turn a bad programmer into a good programmer.
• Principle have to be applied with judgement.
• If they are applied by rote it is just as bad as if they are not applied at all.

Euclip once said to a king who wanted the short version - "There is no royal road to Geometry."

If you want to learn these principles well enough to be able to apply them, then you have to study them. This is not easy but rewarding.

So how do I get started?

• Search your own code, and the code of others, for applications and violations of the principles.
• Determine whether those applications and violations were justified.
• Improve the designs by applying one or more principles and see if the result is actually better.

Alright, so before we move forward, just try to identify Symptoms of Bad Code and remember three words.

• Rigidity: Every change affects many other parts
• Fragility: Things break in unrelated places
• Immobility: Cannot reuse code outside of its original context

How do we fix these problems? - S.O.L.I.D. TO THE RESCUE!