SOLID principles

As a software developer, there is always something new to learn.  There's always a new hot language to learn, framework to apply or tool to try.

For anyone who doesn't have a formal education in computer science, like myself, there's also a lot of old concepts to learn.  Importantly, you should prioritize learning these old gems before filling your head with the newest trend.

The old stuff has stood the test of time, so it's probably been useful somewhere.  And if it's been used, it's also been criticized; so you can learn from that too.

Even if the old concept is fatally flawed, they are part of the lexicon and of the computer science knowledge base.  Someone might refer to these concepts in describing a new concept.  So, being unaware of the past may make it harder to keep up with the future. 

The last few days I have been reading about SOLID.  This qualifies as an 'old' concept (or concepts).  It's an acronym for the "first five principles" of object oriented design.  Basically, when you are writing code, it should follow these principles, and if you don't, you better have a good reason why you are not. 

There isn't much I could add to the discussion that hasn't been discussed thoroughly.  But for my own sake, I thought I'd define each of them again in my words.

S - Single responsibility.

Make sure your classes are responsible for one thing and only one thing.  You want modular components, not a single "God" object that can do everything.  The primary benefit of this is encapsulation.

O - Open / Closed Principle

Write code that is open for extension, but closed from modification.  When you are adding features, you want to write new code, and not have to modify old stuff.

L - Liskov Substitution Principle

I don't like the name of this principle.  'Liskov' doesn't mean anything to me.  It really should be called the 'Substitution principle'.  Anyway ...

Wherever you using a base class, you should be able to substitute a derived class.  Make sure your derived class D "IS-A" subtype of base class B.  Because your public interface will depend on virtual methods, make sure your derived class D behaves like a base class B, except

I - Interface segregation Principle

It's better to set up lots of client specific interfaces than just a few general interfaces.  Fat interfaces will have lots of unintended dependencies.

D - Dependency Inversion Principle

The name of this principle is confusing too.  It sounds like I should should invert or reverse the direction in which modules depend on one another.  But what if I had the dependency relationships correct in the first place?

In any case, I think the point of this principle is that all concrete classes should depend on abstract ones.  Say you have some object and you want to save its data to a database.  You should have the object depend on some abstract database writer.  When you want to change the way you write to a database, you can modify the database writer and not have to modify the object.

SOLID

So, those are the solid principles.  You can get by as a programmer without actually knowing of these principles.  But it makes a lot of sense for any programmer to spend some time becoming familiar with these concepts and terms.  It helps when you are designing your classes and it helps when you want to communicate with fellow programmers.