Software Engineering. 8. Prinzipien objektorientierten Designs. Franz-Josef Elmer, Universität Basel, HS 2010

Transkript

1 Software Engineering 8. Prinzipien objektorientierten Designs Franz-Josef Elmer, Universität Basel, HS 2010

2 Software Engineering: 8. Prinzipien objektorientierten Designs 2 Warum Prinzipien? Geben Hinweise, wie man das Design anpacken soll. Helfen typische Fehler zu vermeiden. Aus Prinzipien wurden Handlungsrichtlinien abgeleitet. Vorgaben für Qualitätsbeurteilung. Aus Prinzipien wurden Metriken abgeleitet, um die Qualität messbar zu machen. Prinzipien sind Erfahrungswissen. Abstrahiert aus langjährigen Erfahrungen. Von anderen übernommen, bestätigt und weiterverbreitet. Aber: Nur wenige empirische Untersuchungen über Wirksamkeit und Relevanz von Designprinzipien.

3 Software Engineering: 8. Prinzipien objektorientierten Designs 3 Ziele des Designs Design ist unsichtbar. Software, die alle funktionalen Anforderungen genügt, kann trotzdem schlecht entworfen sein. Design ist gut wenn es die Komplexität der Software in handhabbare und einfache Probleme herunterbricht die Entwicklung zügig verläuft die Software wartbar ist die Software leicht geändert und erweitert werden kann die Software stabil ist Bugs schnell behebbar sind die Software in anderen Softwareprojekten wiederverwendbar ist der Code verständlich ist

4 Software Engineering: 8. Prinzipien objektorientierten Designs 4 Symptome verfaultem (eng. rotten) Designs Never-touch-running-code Syndrom: Entwickler haben Angst undurchschaubaren Code zu ändern. Es wird Code darum herum entwickelt (workaround). So entsteht toter Code, d.h. Code der (wahrscheinlich) nie ausgeführt wird. Änderungen haben unbekannte und unerkannte Seiteneffekte: Z.B. Bugfixing produziert weitere Bugs, die erst viel später (sprich: beim Kunden!) gefunden werden. Eine kleine Änderung in den Anforderungen führt zu grossen Änderungen im Code: Z.B. sollen alle Datumsanzeigen von zweistellige auf vierstellige Jahreszahlen umgestellt werden (Y2K Problem). Copy-Paste Sünde: Wiederverwendung durch Codeduplikation (mit oder ohne kleine Änderungen). Entwickler jagen den Stellen hinterher die geändert werden müssen, falls sich die Logik geändert hat.

5 Software Engineering: 8. Prinzipien objektorientierten Designs 5 Allgemeine Designprinzipien KISS: Keep It Simple, Stupid DRY: Don't Repeat Yourself Separation of Concerns Design by Contract Geheimnisprinzip (Information Hiding)

6 Software Engineering: 8. Prinzipien objektorientierten Designs 6 KISS (Keep It Simple, Stupid) Prinzip Immer nach der einfachsten und klarsten Lösung suchen. Keine Optimierung der Performanz auf Kosten der Verständlichkeit und Modularität. Erhöht die Verständlichkeit des Codes. Vermeidet never-touchrunning-code Syndrom. Aber: KISS quick and dirty Verwandt mit dem YAGNI Prinzip (You Aren't Gonna Need It) aus extreme Programming, d.h. nur soviel Funktionalität wie nötig entwerfen und implementieren. So einfach wie möglich, aber nicht einfacher! Nicht in eine Richtung verallgemeinern, die später nie gebraucht wird. Beispiel: Braucht ein Interface neben einer add() Methode auch eine remove() Methode? Aber: Design offen halten für nicht erwartete Erweiterungen. Erst mittels Profiling die Engpässe aufspüren und nur diese beheben.

7 Software Engineering: 8. Prinzipien objektorientierten Designs 7 DRY (Don't Repeat Yourself) Prinzip Jedes Wissen, jede Information (Daten, Metadaten, Logik, Funktionalität, Algorithmus, etc.) wird nur an einer massgebenden Stelle im System kodiert bzw. repräsentiert. Vermeidung von Problemquellen wie: Ausnahmen: Copy-Paste Sünde Codeduplikation Automatische Synchronisation (z.b. Codegenerator) Automatische Detektion von Asynchronität (z.b. durch den Compiler) Grosse technologische Hindernisse Performanzprobleme In Stein gemeisselte Wissensschnipsel (z.b. Kreisfläche) aber nicht Berechnung der Mehrwertsteuer (kann sich ändern) Fläche eines beliebigen Polygons (komplexer Algorithmus)

8 Software Engineering: 8. Prinzipien objektorientierten Designs 8 Separation of Concerns Aufteilung der verschiedenen Anliegen: Sachanliegen (aus den Anforderungen) technische Anliegen (z.b. Datenpersistenz, Datenverarbeitung, Datenpräsentation) Führt zur Zerlegung der Software in Schichten Module Komponenten Objekte Konsequenz: Schnittstellen zwischen den Teilen

9 Software Engineering: 8. Prinzipien objektorientierten Designs 9 CRC Karten CRC = Class-Responsibility-Collaborators Designtechnik um Separation of Concerns umzusetzen Eine Karte pro Klasse (Interface, Komponente, Schicht, etc.) mit 3 Sektoren: Das Design-Meeting beginnt mit leeren Karten. Durch Diskussion und Rollenspiel wird versucht aus den Anforderungen bzw. Spezifikationen herauszufinden: Class Resp. Klassenname Coll. Verantwortlichkeiten der Klasse Andere Klassen mit denen diese Klasse zusammenarbeitet Welche Klassen es braucht. Wie sie heissen sollen. Für was welche Klasse zuständig ist. Wie die Klassen untereinander kommunizieren. All das wird auf den Karten notiert, durchgestrichen, geändert etc.

10 Software Engineering: 8. Prinzipien objektorientierten Designs 10 Schnittstelle Teil A Teil B Datenfluss Typen von Schnittstellen: Schnittstelle Eine Schnittstelle repräsentiert den öffentlichen Aspekt eines Teils des Systems. Sie trennt Absicht von Realisierung Abstraktion von Implementierung (Geheimnisprinzip) Client von Service Benutzer von Autor Funktionen die in C Header Dateien als API deklariert sind. Öffentliche (public) Attribute und Operationen einer Klasse Das Sprachkonstrukt Interface in Sprachen wie Java, C#, etc.

11 Software Engineering: 8. Prinzipien objektorientierten Designs 11 Design by Contract Konzept von Bertrand Meyer zum Entwurf von Schnittstellen. Idee: Eine Schnittstelle ist ein Vertrag (eng. contract) zwischen Client und Service (Realisierung der Schnittstelle). Im Vertrag steht für jede Operation die Vorbedingung (eng. precondition), die erfüllt sein muss bevor die Operation aufgerufen wird, die Nachbedingung (eng. postcondition), die der Service garantiert. Vorbedingung und Nachbedingung sind Zusicherungen (eng. assertions). Das sind Boolesche Ausdrücke, die wahr sind, wenn der Vertrag eingehalten wird. Ausnahmen (eng. exceptions) werden geworfen wenn die Voraussetzungen nicht erfüllt wurden oder der Service die Nachbedingung nicht einhalten kann.

12 Software Engineering: 8. Prinzipien objektorientierten Designs 12 Geheimnisprinzip (Information Hiding) Unterscheidung zwischen dem was ein Teil des Systems (Module, Komponente oder Klasse) macht und dem wie es seine Aufgabe erfüllt. WAS: Schnittstelle. Diese ist offen und bekannt. WIE: Implementierung. Diese ist versteckt. Kommunikation zwischen den Teilen via Schnittstellen Verhindert unerwünschte Kopplungen zwischen Teilen des Systems. Reduziert die Komplexität. Erlaubt unabhängige Entwicklung von Modulen, Komponenten, bzw. Klassen. Voraussetzung: Schnittstelle ist stabil und gut dokumentiert. Erlaubt Testbarkeit einzelner Module, Komponenten, bzw. Klassen. Dummies und Mocks der Schnittstellen ersetzen den Rest des Systems.

13 Software Engineering: 8. Prinzipien objektorientierten Designs 13 Geheimnisprinzip und Kapselung Geheimnisprinzip Kapselungsprinzip der OOP Beispiel: Kapselung fasst Daten und Methoden zusammen (Objekte). Die Kapsel kann transparent oder undurchsichtig sein. Kapselung: Daten (Attribute) nicht direkt sichtbar. public class NoInformationHidingNorEncapsulation { public ArrayList points = new ArrayList(); public class NoInformationHidingButEncapsulation { private ArrayList points = new ArrayList(); public ArrayList getpoints(){ return points; ArrayList List public class InformationHidingAndEncapsulation{ private ArrayList points = new ArrayList(); public List getpoints(){ return points; public class InformationHidingWithoutEncapsulation { public List points = new ArrayList(); Quelle:

14 Software Engineering: 8. Prinzipien objektorientierten Designs 14 Objektorientierte Designprinzipien Open-Closed Prinzip Liskovsche Substitutionsprinzip Komposition vor Vererbung Prinzip der minimalen Kopplung Prinzip der maximalen Kohäsion Prinzip der Umkehrung von Abhängigkeiten Prinzip der azyklischen Abhängigkeit

15 Software Engineering: 8. Prinzipien objektorientierten Designs 15 Open-Closed Prinzip Eine wiederverwendbare Klasse sollte offen sein für Erweiterungen, aber geschlossen für Änderungen. (Bertrand Meyer, 1988) D.h. der Code der Klasse muss nicht geändert werden, um dem System ein neues Feature hinzuzufügen. Mögliche Umsetzungen dieses Prinzips: Subklasse bilden und Methode überschreiben. Bestehende Klassen durch Delegation wiederverwenden. Frameworks sind Beispiele für die Anwendung dieses Prinzips: Um Frameworks benutzen zu können, müssen Basisklassen erweitert, Interfaces implementiert werden. Frameworks sind i.r. 3 th -party Software und als solche nicht änderbar (ausser bei Open Source).

16 Software Engineering: 8. Prinzipien objektorientierten Designs 16 Open-Closed Prinzip: Beispiel Folgendes Codefragment verletzt dieses Prinzip: public void draw(form form) { if (form.type == CIRCLE) { drawcircle(form); else if (form.type == SQUARE) { drawsquare(form); Die Methode draw() soll eine geometrisch Form zeichnen. Falls das Programm um eine neue Form (z.b. Dreieck) erweitert wird, muss diese Methode angepasst werden. Lösung durch Polymorphismus: «Interface» Form draw() public void draw(form form) { form.draw(); Circle Square Triangle

17 Software Engineering: 8. Prinzipien objektorientierten Designs 17 Liskovsche Substitutionsprinzip Instanzen von einer Klassen können durch Instanzen ihrer Subklasse ersetzt werden. (Barbara Liskov, 1988) Beispiel: Client Base Derived D.h. statt mit einem Objekt der Klasse Base arbeitet Client genauso gut mit einem Objekt der Subklasse Derived. Das ist nicht selbstverständlich, da sich die abgeleitete Klasse anders verhalten kann als die Basisklasse.

18 Software Engineering: 8. Prinzipien objektorientierten Designs 18 Liskovsche Substitutionsprinzip: Beispiel Klasse: Subklasse: public class Ellipse { private Point focus1; private Point focus2; public void setfoci(point f1, Point f2) { focus1 = f1; focus2 = f2; public Point getfocus1() { return focus1; public Point getfocus2() { return focus2; public class Circle extends Ellipse { public void setfoci(point f1, Point f2) { focus1 = f1; focus2 = f1; Folgender Clientcode wirft ein AssertionError: public void test(ellipse e) { Point p1 = new Point(1, 0); Point p2 = new Point(-1, 0); e.setfoci(p1, p2); assert e.getfocus2().equals(p2);

19 Software Engineering: 8. Prinzipien objektorientierten Designs 19 Liskovsche Substitutionsprinzip: Regel Die Verletzung des Liskovschen Substitutionsprinzips zeigt sich erst zur Laufzeit. Folgende Regeln garantieren die Einhaltung das Liskovschen Substitutionsprinzips: 1.Die Vorbedingungen an die überschriebenen Methoden sind nicht strenger als die für die Basisklasse. Aussagelogisch: precondition class precondition subclass 1.Die Nachbedingung an die überschriebenen Methoden sind nicht schwächer als die für die Basisklasse. Aussagelogisch: postcondition subclass postcondition class

20 Software Engineering: 8. Prinzipien objektorientierten Designs 20 Komposition vor Vererbung Vererbung: A work() B work() Überschreibt Methode der Superklasse Komposition: Delegiert an a: a.work() B work() a 1 A work() Vererbung problematisch: Liskovsche Substitutionsprinzip kann verletzt werden. Starke Abhängigkeit zwischen Subklasse und Basisklasse Verletzung des Geheimnisprinzips möglich: Verhalten der Subklasse kann von Implementierungsdetails der Superklasse abhängen.

21 Software Engineering: 8. Prinzipien objektorientierten Designs 21 Problematische Vererbung: Beispiel Subklasse von HashSet: Zähl wie oft versucht wurde ein Objekt hinzuzufügen. import java.util.*; public class MonitoredSet extends HashSet { private int addcounter; public int getaddcounter() { return addcounter; public boolean add(object object) { addcounter++; return super.add(object); public boolean addall(collection collection) { addcounter += collection.size(); return super.addall(collection); Dies führt in folgendem Codefragment zu einem AssertionError: MonitoredSet set = new MonitoredSet(); set.addall(arrays.aslist(new String[] { a, b, c ); assert set.getaddcounter() == 3; «Interface» Set HashSet MonitoredSet

22 Software Engineering: 8. Prinzipien objektorientierten Designs 22 Problematische Vererbung: Komposition Lösung: MonitoredSet delegiert an HashSet: import java.util.*; public class MonitoredSet implements Set{ private Set set = new HashSet(); private int addcounter; public int getaddcounter() { return addcounter; public boolean add(object object) { addcounter++; return set.add(object); public boolean addall(collection collection) { addcounter += collection.size(); return set.addall(collection);... «Interface» Set MonitoredSet 1 HashSet

23 Software Engineering: 8. Prinzipien objektorientierten Designs 23 Regeln für Vererbung Vererbung (B ist Subklasse von A) ist unproblematisch wenn: Objekt vom Typ B ist eine spezielle Art von A und nicht ist eine Rolle von A. B erweitert A. Es wird keine Operation überschrieben. B überschreibt Operationen von A, die ausdrücklich überschrieben werden dürfen (z.b. die Methode init() der Klasse java.applet.applet). A ist Teil einer schlecht entworfenen 3 th -party API. Im Zweifelsfall: Komposition statt Vererbung

24 Software Engineering: 8. Prinzipien objektorientierten Designs 24 Prinzip der minimalen Kopplung Keine Kopplung zwischen Klassen, die nicht eine gemeinsame Aufgabe erfüllen. Kopplung zwischen Modulen bzw. Komponenten nur über Schnittstellen. Interface Klasse Abhängigkeit

25 Software Engineering: 8. Prinzipien objektorientierten Designs 25 Prinzip der maximalen Kohäsion Starke Kopplung zwischen Klassen, die eine gemeinsame Aufgabe erfüllen. Klassen, die eine gemeinsame Aufgabe erfüllen, gehören zusammen in ein Paket. Klassen, die nur schwach gekoppelt sind, gehören in verschiedene Pakete (Separation of Concerns auf Paketebene).

26 Software Engineering: 8. Prinzipien objektorientierten Designs 26 Prinzip der Umkehrung von Abhängigkeiten Abstraktionen sollen nicht von Details abhängen, sondern umgekehrt. (Robert C. Martin, 1995) Typische Abhängigkeiten in prozeduralen Systeme: Hauptprogramm Funktion 1 Funktion 2 Funktion A Funktion B Funktion C Umkehrung der Abhängigkeiten: Main «Interface» I1 «Interface» I2 Implementation1 Implementation2

27 Software Engineering: 8. Prinzipien objektorientierten Designs 27 Prinzip der azyklischen Abhängigkeit Der Graph der Abhängigkeiten zwischen Modulen bzw. Paketen sollte azyklisch sein. (John Lakos, 1996, Robert C. Martin, 1996) Zyklische Abhängigkeiten sind problematisch weil grösserer Aufwand in der Wartung, bezüglich Erweiterungen, beim Testen. Zyklische Abhängigkeiten zwischen Klassen sind vertretbar wenn alle Klassen im selben Paket, nur eine handvoll Klassen involviert sind.

28 Software Engineering: 8. Prinzipien objektorientierten Designs 28 Zyklische Abhängigkeiten auflösen Zwischen Klassen: Interface einführen A A «Interface» IB C B C B Ursache zyklischer Abhängigkeiten von Paketen: Klassenzyklus mit Klassen in verschiedenen Paketen. Auflösung: Siehe oben Klasse(n) in falschem Paket Auflösung: Klasse(n) verschieben p Paketname r p r A B q D A q B D C C UML Paket Notation

29 Software Engineering: 8. Prinzipien objektorientierten Designs 29 Links Wiki zu OO Design (und andere IT Themen): Martin Fowler's Web Site: