Pablo’s Topic of the Month – March: SOLID Principles

Over the next few days and weeks, the Los Techies crew will be writing a number of blog posts focused a particular subject in addition to their regular blogging.  Pablo’s Topic of the Month for the month of March is Bob Martin’s S.O.L.I.D. design principles. We’ll try to cover all of them by the end of the month or we might focus in on a few of them and go really deep.  Please stay tuned and please give us some feedback of how you like this format because we’re considering doing it in upcoming months.

If you haven’t already, please consider subscribing to the Los Techies Main Feed so that you can see the various post from the other Los Techies bloggers.

The main feed is here:  https://feeds.feedburner.com/lostechies 

What is S.O.L.I.D.?

S.O.L.I.D. is a collection of best-practice object-oriented design principles that you can apply to your design to accomplish various desirable goals like loose-coupling, higher maintainability, intuitive location of interesting code, etc.  S.O.L.I.D. is an acronym for the following principles (which are, themselves acronyms — confused yet?).

These principles were pioneered and first collected into a written work by Robert ‘Uncle Bob’ Martin. You can find more details here: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

I’m going to give you a teaser here of each one, but I won’t go into much detail here as that’s what the other Los Techies articles are going to be about.  Please check back to this post as I’ll be updating it with links to other posts as they appear so you can keep tabs on what’s going on. 

The attribution of the following snippets goes to Robert Martin from various publications.

SRP: Single Responsibility Principle

THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.

• PTOM: The Single Responsibility Principle by Sean Chambers

  • POTM: The Single Responsibility Principle by J.D. Meridth</ul>

  OCP: Open Closed Principle

  SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION.

  • PTOM: The Open Closed Principle by Joe Ocampo
    • PTOM: OCP Revisited in Ruby by Joe Ocampo</ul>

      LSP: Liskov Substitution Principle

    FUNCTIONS THAT USE … REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES  WITHOUT KNOWING IT.

    • PTOM: The Liskov Substition Principle by Chad Myers — My own post on the subject

      ISP: Interface Segregation Principle

    CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE

    • PTOM: The Interface Segregation Principle by Ray Houston

      DIP: Dependency Inversion Principle

    A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS

    B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS

    • PTOM: The Dependency Inversion Principle by Jimmy Bogard