Komponenten-basierte Entwicklung. Teil 17: Einige Prinzipien guter Software- Entwicklung

Transkript

1 Komponenten-basierte Entwicklung Teil 17: Einige Prinzipien guter Software- Entwicklung Komponenten WS 2014/15 Teil 17/Gute Software

2 Literatur [17-1] Martin, Robert: Clean Code. Mitp, 2009 [17-2] Passig, Kathrin; Jander, Johannes: Weniger schlecht programmieren. O'Reily, 2013 [17-3] Martin, Robert: Principles of OOD. [17-4] Martin, Robert: Agile Software Development. Principles, Patterns, and Practices. Prentice Hall, 2002 [17-5] Hunt, Andrew; Thomas, David: The Pragmatic Programmer. Addison- Wesley, 2000 [17-6] Pragmatic Programmer Quick Reference Guide: [17-7] Liskov, B. H.; Wing, J. M. (November 1994). "A behavioral notion of subtyping". ACM Trans. Program. Lang. Syst. 16 (6): Verbesserte Version: [17-8] Martin, Robert: The Liskov Substitution Principle. C++ Report, Komponenten WS 2014/15 Teil 17/Gute Software 2

3 Robert Martins Meinung Bei komplexen Software-Produkten sollten folgende Aspekte beachtet werden, siehe dazu [17-4]: Rigidity: Bei jeder Änderung muss beachtet werden, dass zu viele oder nicht beabsichtigte Teile zugleich verändert werden. Fragility: Bei jeder Änderung können unerwartet andere Teile der Software fehlerhaft werden. Immobility: Es ist schwer einen Teil bestehender Software zwecks Wiederverwendung aus seinem Kontext heraus zu lösen. Um dieser drei Aspekte zu reduzieren dienen die in diesem Teil vorgestellten Prinzipien. Komponenten WS 2014/15 Teil 17/Gute Software 3

4 Information Hiding I Es dürfen nur Informationen über die Benutzung einer Schnittstelle erkennbar sein, nie Informationen über die Implementierung. Die zur Benutzung erforderlichen Informationen (Parameterliste, Datentypen) müssen auch minimal sein. Durch die Trennung (Abstraktion) der Schnittstelle von deren Implementierung, kann ohne Modifikation der benutzenden Software die betreffende Sache (Klasse, Modul, Funktion etc.) geändert werden. Unter Schnittstelle werden in Java nicht nur Interfaces, sondern auch Signaturen von Methoden sowie Typ und Name von public-attributen verstanden. Komponenten WS 2014/15 Teil 17/Gute Software 4

5 Information Hiding II - Variante Die Sichtbarkeit einer Schnittstelle muss so klein wie möglich sein. Statt public sollte protected oder noch besser private benutzt werden, wenn nicht andere Gründe dagegen sprechen. Grund: Die Auswirkungen von Änderungen sollten so klein wie möglich sein, oder: der von einer Sache unabhängige Bereich sollte so groß wie möglich sein. Denn: Etwas nicht Sichtbares kann nicht benutzt werden. Komponenten WS 2014/15 Teil 17/Gute Software 5

6 DRY Don't Repeat Yourself Jede innerhalb der Software gelöste (Teil-)Aufgabe hat nur eine einzige Stelle der Implementierung. Dadurch ist eine Fehlerbeseitigung nur an einer Stelle notwendig. Wenn an mehreren Stellen Dasselbe oder Ähnliches realisiert wurde, können bei Fehlerbeseitigungen Stellen vergessen werden. Der Code-Umfang wird kleiner. Kurzer Code ist leichter zu verstehen als langer Code. Komponenten WS 2014/15 Teil 17/Gute Software 6

7 Design by Contract I Die Benutzung von Teilen einer Software verläuft über eine Schnittstelle (Interface), die als Vertrag fungiert. Ein Vertrag besteht aus Preconditions = Bedingungen, die der Vertrag voraussetzt, also zum Beginn der Benutzung erfüllt sein müssen Postconditions = Bedingungen, die nach Benutzung gelten Invarianten = Bedingungen, die während der Ausführung immer erfüllt sind Die Idee stammt von Bertrand Meyer, dem Erfinder der Programmiersprache Eiffel. Komponenten WS 2014/15 Teil 17/Gute Software 7

8 Design by Contract II Verträge/Schnittstellen zwischen Teilen von Software bilden die Basis für Unit-Tests, die möglichst automatisiert ablaufen sollten. Die Spezifikation einer Schnittstelle einer Unit" (Klasse, Funktion, Modul, Komponente) sollte das einzige sein, das getestet wird. Umgekehrt: Immer gegen Schnittstellen, nie gegen (spezielle) Implementierungen programmieren. Oder anders: Nie spezielle Eigenschaften, z.b. public-variablen, bei der Benutzung ausnutzen oder voraussetzen. Komponenten WS 2014/15 Teil 17/Gute Software 8

9 Exceptions Verwende Exceptions nur Behandlung von Problemen, die ein Benutzer/Aufrufer selbst lösen kann. Verwende Exceptions nur bei Verletzung der Vorbedingungen des Vertrages. Nicht behandelbare Ausnahmen sollten zum Abbruch nach einem Logging und einer ausführlichen Diagnose führen, z.b. Plattenfehler oder Durchtrennung eines Ethernet-Kabels. Behandelbare Ausnahmen werden häufig durch Prüfung eines bestimmten Zustands festgestellt. Ob solch ein Zustand vorliegt, kann der Benutzer durch eine sog. State-Testing Methode, z.b. im Iterator-Interface hasnext(), erfragen. Komponenten WS 2014/15 Teil 17/Gute Software 9

10 SOLID Single responsibility principle Eine Klasse soll genau eine Aufgabe lösen. Open/closed principle Funktionserweiterungen sollten nicht durch Modifikation der Codes erfolgen. Liskov substitution principle Unterklassen dürfen die Verträge ihrer Superklassen nicht verletzen. Interface segregation principle Interfaces sollen nicht allgemein, sondern spezifisch auf das Ziel gerichtet sein. Dependency inversion principle Abhängigkeiten sollten immer von benutzten Klassen zu benutzenden bestimmt werden. Komponenten WS 2014/15 Teil 17/Gute Software 10

11 Single responsibility principle I Realisiere eine Klasse immer so, dass sie genau eine Aufgabe vollständig, also in sich geschlossen, löst. Responsibility = eigentlich Verantwortung, hier Aufgabe oder Aufgabenlösung Anders formuliert: Es gibt immer nur einen einzigen Grund eine Klasse zu verändern, nämlich Beseitigung eines Fehlers oder Verbesserung der Performanz einer einzigen Aufgabenlösung. Durch dieses Prinzip werden die Klassen kleiner und einfacher zu verstehen. Typische Verletzungen dieses Prinzips: Die Klasse und ihre Erzeugung zusammen zu fassen, z.b. im Singleton-Muster. Komponenten WS 2014/15 Teil 17/Gute Software 11

12 Single responsibility principle II Zerlege komplexe Aufgaben in Teilaufgaben, die jeweils in separaten Klassen gelöst werden. Das Zerlegen kann nach der traditionellen Methode der Schrittweisen Verfeinerung (Stepwise Refinement) erfolgen. Typisch maximale Klassengrößen (zur Orientierung): Methode: Zeilen (Bildschirmgröße) Klasse: Zeilen Dies ohne Kommentare und Leerzeilen. Hiervon kann es berechtigte Ausnahmen geben, z.b. aufgrund von switch-statements. Komponenten WS 2014/15 Teil 17/Gute Software 12

13 Open/closed principle I Klassen sollen offen für Erweiterungen, aber gleichzeitig geschlossen für Veränderungen bestehenden Codes sein. Jede bestehende Klasse erfüllt einen Vertrag, an den sich alle diese Klasse benutzenden Klassen halten. Eine Veränderung dieses Vertrags durch Erweiterung der Funktionalität aufgrund von Code-Modifikation führt zu sehr komplexen Veränderungen, daher geschlossen". Wenn die realisierte Aufgabe vollständig ist (Single responsibility principle), kann durch eine einfache Vererbung eine neue Funktionalität und damit ein neuer Vertrag realisiert werden. Komponenten WS 2014/15 Teil 17/Gute Software 13

14 Open/closed principle II Class_A meth_a() Class_B meth_c() Vertrag A Vertrag B Die Methode kann nur dann sinnvoll überschrieben werden, wenn die neue Semantik nicht mit der alten meth_b (aus Class_A) kollidiert. Der Vertrag durch Class_B sind anders als der Vertrag A aus. Software, die nach Vertrag_A die Klasse Class_A benutzen, können dies unabhängig weiter tun. Dies ist ein typisches Beispiel für eine semantische Erweiterung ohne Effekte auf bestehende Software. Komponenten WS 2014/15 Teil 17/Gute Software 14

15 Open/closed principle III - Variationen Class_A meth_a() <<interface>> Interface_A meth_a() <<realize>> <<realize>> Class_B CLass_C Class_A Class_B meth_a() meth_a() meth_a() meth_a() Hier bleibt eine abstrakte Klasse "geschlossen". Hier ist es ein Interface, was "geschlossen" ist und trotzdem erweitert wird. Komponenten WS 2014/15 Teil 17/Gute Software 15

16 Liskov substitution principle I Entwirf Unterklassen immer nur so, dass dessen Objekte den Vertrag Ihrer Oberklasse erfüllen können. Dieses Prinzip geht auf Barbara Liskov zurück, die dies so beschrieben hat [17-7]: Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S, where S is a subtype of T. Anders ausgedrückt: Objekte von Unterklassen, die diesen Prinzip gehorchen, können Objekte ihrer Oberklasse in Programmen, die nur die Oberklasse benutzen, ersetzt werden, ohne dass die Software fehlerhaft wird. Komponenten WS 2014/15 Teil 17/Gute Software 16

17 Liskov substitution principle II Oder noch anders ausgedrückt: Vererbung sollte nur so benutzt werden, dass die Semantik der Oberklasse bei der Benutzung der Unterklasse erhalten bleibt. Class_C call meth_a() Class_A Class_A Call meth_a() meth_a() Class_B Class_C Class_B call meth_a() meth_c() meth_c() call So programmiert und muss auch so laufen Komponenten WS 2014/15 Teil 17/Gute Software 17

18 Interface segregation principle Achte darauf, dass Schnittstellen minimal in dem Sinne sind, dass nur eine einzige Aufgabe damit erfüllt wird. Segregation = hier: Aufteilung, Trennung Komplexe Leistungen sollen auf mehrere Schnittstelle, die sinnvolle Teilaufgaben lösen erlauben, aufgeteilt werden. Diese Teilschnittstellen können über umfassende zusammengefasst werden, wobei die Benutzung der Zusammenfassung nicht erzwungen ist. Komplexe Schnittstelle für mehrere Aufgaben würden Klasse dazu zwingen, mehr als eine Aufgabe zu erfüllen, was ein Verstoß gegen das Single Responsibility Prinzip wäre. Es darf die Implementierung von Methoden nicht erzwungen werden, die auf der benutzende Seite nicht benutzt werden. Komponenten WS 2014/15 Teil 17/Gute Software 18

19 Dependency inversion principle I Die Verknüpfung von benutzten Klassen/Objekten sollte immer unabhängig von den benutzenden Klassen/Objekten erfolgen. Anders formuliert: Die Bestimmung von welcher Klasse/Objekt eine Abhängigkeit besteht liegt nicht in der Hand der Klasse, die die Abhängigkeit eingeht. Oder: Der Zusammenbau von Objekten (Linking) wird nicht von der benutzenden Seite bestimmt. Der Code muss so gestaltet werden, das diese Umkehrung der Kontrolle realisiert werden kann. Eine Art dies zu implementieren ist Dependency Injection. Komponenten WS 2014/15 Teil 17/Gute Software 19

20 Dependency inversion principle II Die Benutzt-Relation sollte immer vom Aufrufer zum Aufgerufenen über eine Schnittstelle erfolgen, um Austauschbarkeit des Aufgerufenen zu gewährleisten. Class_A <<call>> <<interface>> Interface Durch den Gang über eine Schnittstelle wird von der konkreten benutzten Klasse abstrahiert. <<realize>> <<realize>> Class_B1 Class_B2 Zwischen Class_A und einer von Class_B liegt ein Interface (als Abstraktion). Class_A hängt vom Interface ab, während alle Class_B's dies implementieren. Komponenten WS 2014/15 Teil 17/Gute Software 20

21 Dependency inversion principle III Die Entscheidung, was ein Aufrufer konkret aufruft, wird dem Aufrufer weggenommen und einer anderen Instanz überlassen. Es geht also um eine Entkopplung zwischen Aufrufer und Aufgerufenen. Der Begriff Dependency ist sehr unglücklich gewählt, da eine Abhängigkeit des Aufrufers immer vom Aufgerufenen besteht. Benutzt Relation = A benutzt B, wenn A von der Korrektheit von B abhängig ist. Komponenten WS 2014/15 Teil 17/Gute Software 21

22 Dependency inversion principle IV Zitat von Robert Martin: 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. Das ist nur dann verständlich, wenn Low-Level-Module, die ja aufgerufen werden, von Interface (Abstractions) auf der Ebene des Compilers abhängen, nicht jedoch auf der Ebene von Objekten. Komponenten WS 2014/15 Teil 17/Gute Software 22

23 Komposition vor Vererbung I Bevorzuge die Komposition gegenüber der Vererbung. Vererbungen erzeugen immer enge Kopplungen und sehr häufig unverständliche Software. Komposition erlaubt per Dependency Injection aufgrund der losen Kopplung auch Freiheit im Zusammenbau von Objekt- Geflechten. Komponenten WS 2014/15 Teil 17/Gute Software 23

24 Komposition vor Vererbung II Class_A meth_a() Class_B myb : Class_A instanziiert Class_A meth_a() <<call>> Class_B In wird meth_a() aufgerufen In wird myb.meth_a() aufgerufen Es wird eine Methode der Oberklasse in aufgerufen. Über eine Instanz von Class_A wird in die Methode aufgerufen. Komponenten WS 2014/15 Teil 17/Gute Software 24

25 Abtrennung von variablen Teilen Trenne absehbar in Zukunft zu ändernde Teile einer Klasse von Dingen, die absehbar konstant bleiben. Verlagere die variable Teile in eigene Klassen und benutze diese über ein Interface. Class_A meth_a() meth_a() ruft auf. Class_A myb : Interface meth_a() <<call>> <<interface>> Interface variiert von Applikation zu Applikation meth_a() ruft myb. auf <<realize>> Class_B1 <<realize>> Class_B2 Enge Kopplung mit variablen Aspekten. Lose Kopplung mit variablen Aspekten. Komponenten WS 2014/15 Teil 17/Gute Software 25

26 Nach dieser Anstrengung etwas Entspannung... Komponenten WS 2014/15 Teil 17/Gute Software 26