SOLID for newbies

Reading about the "SOLID" principles, or "making code more SOLID" can put the wind up you if you don't know what it means. I mean, we all know coding loves an an acronym, and I for one can find them intimidating. But it's like someone very important once said - Everything is impossible until you know how to do it. Then everything is trivial. (Sorry, important famous person, for butchering your words).

Case in point - DRY. You might, as a beginner learning to code for the first time, see articles or people talking about "Making your code more DRY... how to write DRY code" etc. You might think this is some special trick or complicated new formula you are going to have to knuckle down and learn.

Fear not, intrepid explorer of new things. It stands for "Don't Repeat Yourself". I mean, come on.

Having said that, it's the simple rules like this that really do make a difference in code. The "best" code is short and clean and doesn't repeat itself unnecessarily, and that is harder to achieve than it sounds.

SOLID is a set of principles which are often considered best practice when writing OO (there I go again - Object Oriented) code.

Let's run through them and try and take the mystery out of them.

S - is for Single Responsibility.
Every class you write should have a single responsibility. Not necessarily a single "job", but a set of properties and methods that relate to a single aim. Which is to say, if you have a nice juicy class that you feel smug about because it's holding all your code and isn't it tidy - that's not good. Split it up. Make more classes - you never know how this code might need to change in the future and someone will thank you later.

O - is for Open/Closed. The long phrase is "Classes should be open to extension, and closed to modification". This is, in a way, an extension of the point made above. You should not start adding stuff into an existing class when you add functionality to an application. Extend the class, and work in there. You won't lose anything, and you shouldn't break anything either, in theory!

L - This is a silly one so hang in there. L stands for Liskov Substitution Principle (I know). You can google it if you want. What it means, roughly speaking, is that any child class should be substitutable for its parent. Is that still Greek? Any child class should be able to be used in the same way its parent can be, even if the outcome is different.

I - is for Interface Segregation. I know it sounds scary but it's really not. This means that no class should implement an interface it doesn't need the entirety of. See letter S above. Your interfaces shouldn't do two things anyway, so if you're an obedient practictioner this one won't be a problem for ya.

D - is for Dependency Inversion. Don't lose it now gang, this is the last one. Again, this is way simpler than it sounds. Don't ask me how the dude who invented this came up with that catchy D, but he did. This means, in short, Type Hint to abstracts or interfaces, not to classes. Type hint to abstractions, not "concretions".

I have been a little nervous to post on here about things that aren't subjective; I felt like I wasn't qualified to do so. But on the other hand, I haunted this board as a complete beginner and I would have appreciated - and did appreciate! People walking through the basics. I hope this helps you go forth and sprinkle your tweets with acronyms to sounds super intellectual.