📝 Add SOLID principles

docs/productive/qa/anti-patterns.rst

@@ -31,6 +31,122 @@ können euch die folgenden Fragen zu weiteren Überlegungen anregen:
 * Hängt jede Methode mehr vom übergebenen Argument ab oder von der Klasse als
   Ganzes?
 
+SOLID-Prinzipien
+----------------
+
+`SOLID
+<https://de.wikipedia.org/wiki/Prinzipien_objektorientierten_Designs#SOLID-Prinzipien>`_
+ist ein Akronym für:
+
+S – :ref:`single-responsibility`
+    Die Methoden einer Klasse sollten auf einen einzigen Zweck ausgerichtet
+    sein.
+O – :ref:`open-closed`
+    Objekte sollten offen für Erweiterungen, aber geschlossen für Änderungen
+    sein.
+L – :ref:`liskov-substitution`
+    Unterklassen sollten durch ihre Oberklassen substituierbar sein.
+I – :ref:`interface-segregation`
+    Objekte sollten nicht von Methoden abzuhängen, die sie nicht verwenden.
+D – :ref:`dependency-inversion`
+    Abstraktionen sollten nicht von Details abhängen.
+
+.. _open-closed:
+
+Open-Closed-Prinzip
+-------------------
+
+Die Entscheidung, ob eine Refaktorierung durchgeführt werden soll, sollte davon
+abhängen, ob euer Code bereits *offen* für neue Anforderungen ist, ohne hierfür
+bestehenden Code ändern zu müssen. Refaktorierungen sollten nicht mit dem
+Hinzufügen neuer Funktionen vermischt sondern beide Vorgänge voneinander
+getrennt werden. Wenn ihr mit einer neuen Anforderung konfrontiert werdet,
+ordnet zunächst den vorhandenen Code so um, dass er für die neue Funktion offen
+ist, und fügt den neuen Code erst hinzu, wenn dies abgeschlossen ist.
+
+    Unter Refaktorierung versteht man den Prozess, ein Softwaresystem so zu
+    verändern, dass das äußere Verhalten des Codes nicht verändert, aber seine
+    innere Struktur verbessert wird.
+
+– `Martin Fowler: Refactoring
+<https://www.mitp.de/IT-WEB/Software-Entwicklung/Refactoring.html>`_
+
+.. note::
+   Sicheres Refactoring ist auf :doc:`Tests <python-basics:test/index>`
+   angewiesen. Wenn ihr den Code wirklich umgestaltet, ohne das Verhalten zu
+   ändern, sollten die vorhandenen Tests bei jedem Schritt weiterhin erfolgreich
+   sein. Die Tests sind ein Sicherheitsnetz, das das Vertrauen in die neue
+   Anordnung des Codes rechtfertigt. Wenn sie versagen,
+
+   * habt ihr den Code versehentlich beschädigt,
+   * oder die vorhandenen Tests sind fehlerhaft.
+
+.. _single-responsibility:
+
+Single-Responsibility-Prinzip
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Das `Single-Responsibility-Prinzip
+<https://de.wikipedia.org/wiki/Single-Responsibility-Prinzip>`_ besagt, dass
+jede Klasse nur eine Aufgabe erfüllen soll:
+
+    Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern.
+
+– `Robert C. Martin: SRP: The Single Responsibility Principle
+<https://web.archive.org/web/20140407020253/http://www.objectmentor.com/resources/articles/srp.pdf>`_
+
+.. _liskov-substitution:
+
+Liskovsches Substitutionsprinzip
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Das `Liskovsche Substitutionsprinzip
+<https://de.wikipedia.org/wiki/Liskovsches_Substitutionsprinzip>`_ besagt, dass
+Unterklassen durch ihre Oberklassen ersetzbar sein müssen. Das
+Liskov-Substitutionsprinzip gilt auch für :ref:`python-basics:duck-typing`:
+jedes Objekt, das behauptet, eine Ente zu sein, muss die API der Ente
+vollständig implementieren. Duck-Types sollten gegeneinander austauschbar sein.
+Die Logik über verschiedene Datentypen von Objekten hinweg anzuwenden, nennt
+sich `Polymorphie
+<https://de.wikipedia.org/wiki/Polymorphie_(Programmierung)>`_.
+
+.. _interface-segregation:
+
+Interface-Segregation-Prinzip
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Das `Interface-Segregation-Prinzip
+<https://de.wikipedia.org/wiki/Interface-Segregation-Prinzip>`_ wendet das
+:ref:`single-responsibility` auf Schnittstellen an um ein bestimmtes Verhalten
+zu isolieren. Wenn eine Änderung an einem Teil eures Codes erforderlich ist,
+eröffnet die Extraktion eines Objekts, das eine Rolle spielt, die Möglichkeit,
+das neue Verhalten unterstützen, ohne dass der bestehende Code geändert werden
+muss. Dies ist kodierten Konkretisierungen vorzuziehen.
+
+In diesem Zusammenhang ist auch das `Gesetz von Demeter
+<https://de.wikipedia.org/wiki/Gesetz_von_Demeter>`_ interessant, das besagt,
+dass Objekte nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren
+sollen. Damit wird die Liste der anderen Objekte wirksam eingeschränkt, an die
+ein Objekt eine Nachricht senden kann und die Kopplung zwischen Objekten
+verringert: ein Objekt kann nur mit seinen Nachbarn sprechen, nicht aber mit den
+Nachbarn seiner Nachbarn; Objekte können nur Nachrichten an direkt Beteiligte
+senden.
+
+.. _dependency-inversion:
+
+Dependency-Inversion-Prinzip
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Das `Dependency-Inversion-Prinzip
+<https://de.wikipedia.org/wiki/Dependency-Inversion-Prinzip>`_ kann definiert
+werden als
+
+    Abstraktionen sollten nicht von Details abhängen. Details sollten von
+    Abstraktionen abhängen.
+
+– `Robert C. Martin: The Dependency Inversion Principle
+<https://www.cs.utexas.edu/users/downing/papers/DIP-1996.pdf>`_
+
 Tyische Code-Smells in Python
 -----------------------------