SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin.
S - Single-responsiblity principle
O - Open-closed principle
L - Liskov substitution principle
I - Interface segregation principle
D - Dependency Inversion Principle
A class should have one and only one reason to change, meaning that a class should have only one job.
Das Single-Responsibility-Prinzip besagt, dass jede Klasse nur eine einzige Verantwortung haben solle. Verantwortung wird hierbei als „Grund zur Änderung“ definiert. Bsp: variabler Outputter (Html/Json) sollte nicht in der Logik sein, sondern in einer eigenen Klasse sein.
Objects or entities should be open for extension, but closed for modification.
offen für Erweiterung aber geschlossen für Modifikation.
siehe auch letztes D-Prinzip: wenn eine Klasse nicht von Abstraktionen sondern von konkreten Implementierungen abhängig ist, ist sie nicht geschlossen, sondern muß modifiziert werden, wenn sich die Abhängigkeit ändert.
Bsp: PasswortReminder-Klasse sollte keine konkrete Mysql-Connnection erfordern, sondern von einer abstrakten Klasse DBConnections o.ä. abhängen, so daß sich die konkrete DB-Engine ändern kann ohne daß diese Klasse angefaßt werden muß.
Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T. All this is stating is that every subclass/derived class should be substitutable for their base/parent class.
Das Liskovsches Substitutionsprinzip (LSP) oder Ersetzbarkeitsprinzip fordert, dass eine Instanz einer abgeleiteten Klasse sich so verhalten muss, dass jemand, der meint, ein Objekt der Basisklasse vor sich zu haben, nicht durch unerwartetes Verhalten überrascht wird, wenn es sich dabei tatsächlich um ein Objekt eines Subtyps handelt.
A client should never be forced to implement an interface that it doesn't use or clients shouldn't be forced to depend on methods they do not use
Clients sollten nicht dazu gezwungen werden, von Interfaces abzuhängen, die sie nicht verwenden. Eine Implementierung sollte nicht gezwungen sein, Methoden zu implementieren, die nicht genutzt werden. Ist eigentlich selbstverständlich, aber sein Bsp. ist da etwas praxisfremd.
interface ShapeInterface {
public function area();
public function volume();
}
ShapeInterface berechnet Fläche und Volumen, wobei zweidimensionale Shapes natürlich kein Volumen haben.
1. Lösung:
interface ShapeInterface {
public function area();
}
interface SolidShapeInterface {
public function volume();
}
Mit Hilfe des Interface-Segregation-Prinzips ist es möglich eine Software derart in entkoppelte und somit leichter refaktorisierbare Klassen aufzuteilen, dass zukünftige fachliche oder technische Anforderungen an die Software nur geringe Änderungen an der Software selbst benötigen. Da sieht er ein Problem für das Typehinting. Deshalb abstrahiert er weiter indem ein ManageShapeInterface mit einer Methode calculate eingeführt wird. Hab ich hier weggelassen.
Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.
„A. Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen. B. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.“
Eine Linkliste zum Thema clean code habe ich hier: