SOLID

solid.md

SOLID

In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the "first five principles" named by Robert C. Martin in the early 2000sthat stands for five basic principles of object-oriented programming and design. The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile and adaptive programming.

S SRP - Single responsibility principle

A class should have only a single responsibility.
(i.e. only one potential change in the software's specification should be able to affect the specification of the class)

Every class should have a single responsibility, and that responsibility should be entirely encapsulated.
All its services should be narrowly aligned with that responsibility, this embraces the high cohesion.

O OCP - Open/closed principle

LEGOS Software entities should be open for extension, but closed for modification.

That is, such an entity can allow its behaviour to be extended without modifying its source code.

http://www.sandimetz.com/blog/2014/05/28/betting-on-wrong "write code that is open to the next change but it says nothing about when to do so."

L LSP

Liskov substitution principle

if mamamal = a than

replace super class with subclass

“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.

I ISP

Interface segregation principle “many client-specific interfaces are better than one general-purpose interface.” not all mammala habe an address mamamls humans address

D DIP - Dependency inversion principle

one should “Depend upon Abstractions. Do not depend upon concretions.”

the way of designing a class structure is to start from high level modules to the low level modules: High Level Classes --> Abstraction Layer --> Low Level Classes

Intent

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

---

Single Responsibilty Principle

A class should never have more than one responsibility

What is this object doing? - if there is more than one answer, make it another class

break at responsibilities or tasks the unix model cohesion set at behaviors

onthology composition interfacing

subclassing Active Record issues - persistanece in datebase doesn't happen and that makes it hard to test

---

Open/closed principle

Liskov substitution principle

Interface segregation principle

Dependency inversion principle