Objektorientierte Komponenten Auf der Basis des Artikels „Integrating Independent Components with On- Demand Remodularization“ von M. Mezini und K. Ostermann.

Präsentation zum Thema: "Objektorientierte Komponenten Auf der Basis des Artikels „Integrating Independent Components with On- Demand Remodularization“ von M. Mezini und K. Ostermann."—  Präsentation transkript:

1 Objektorientierte Komponenten Auf der Basis des Artikels „Integrating Independent Components with On- Demand Remodularization“ von M. Mezini und K. Ostermann

2 1.1 Motivation  Generische Funktionalitäten in Komponenten kapseln  Bereits bestehende Software durch diese Komponenten jederzeit erweitern können (on-demand remodularization)  Dabei keine physische Veränderung der zu erweiternden Software

3 Bsp: Universitätssoftware und Graphenalgorithmen

4

5 Übersicht 1 Einführung 1.1 Motivation 1.2 Problemstellung 2 Konzept 2.1 Collaboration Interface 2.2 Wrapper Recycling 2.3 Wiederverwendung und Polymorphie 3 Fazit

6 1.2 Problemstellung  Fehlen zweier wichtiger Eigenschaften im traditionellen Interface-Konzept 1.Unterstützung für das Design generischer Komponenten 2.Bidirektionale Kommunikation zwischen Klient und Server

7 Bsp: TreeModel Interface (Java Swing) interface TreeModel { Object getRoot(); Object[] getChildren(Object node); String getStringValue(Object node, boolean selected, boolean expanded, boolean leaf, int row, boolean focus); } interface TreeGUIControl { display(); } class SimpleTreeDisplay implements TreeGUIControl { TreeModel tm;... display() { Object root = tm.getRoot();... tm.getChildren(root)... // prepare parameters for getStringValue... tm.getStringtValue(...);... }

8 Bsp: TreeModel Interface (Java Swing) interface TreeModel { Object getRoot(); Object[] getChildren(Object node); String getStringValue(Object node, boolean selected, boolean expanded, boolean leaf, int row, boolean focus); } interface TreeGUIControl { display(); } Sehr häufige Verwendung des Typs Object ! => Konzeptionell fragwürdig => Verlust der Typ-Sicherheit

9 Bsp-Implementierung von TreeModel class ExpressionDisplay implements TreeModel { Expression root; ExpressionDisplay(Expression r) { root = r; } Object getRoot() { return root; } Object[] getChildren(Object node) { return ((Expression) node).getSubExpressions(); } String getStringValue(Object node, boolean selected, boolean expanded, boolean leaf, int row, boolean focus){ String s = ((Expression) node).description(); if (focus) s =" "; return s; } Verlust der Typsicherheit

10 Abgewandeltes TreeModel interface TreeModel { TreeNode getRoot(); } interface TreeNode { TreeNode[] getChildren(); String getStringValue(boolean selected, boolean expanded, boolean leaf, int row, boolean focus); }

11 Einschub: Wrapper-Klassen Definition des Begriffs „Wrapper“:  to wrap (engl.) = verpacken, einhüllen  Extraktion von Daten aus einer Datenquelle  Stellt eine Schnittstelle zur Manipulation dieser Daten dar  In Java gibt es z.B. für jeden primitiven Datentyp eine Wrapper-Klasse.  Integer ist eine Wrapper-Klasse für den primitiven Typ int

12 Bsp: TreeNode-Wrapper für Expression interface TreeNode { TreeNode[] getChildren(); String getStringValue(boolean selected, boolean expanded, boolean leaf, int row, boolean focus); } class ExpressionNode implements TreeNode { Expression expr; ExpressionNode(Expression expr) { this.expr = expr; } TreeNode[] getChildren() { Expression[] subExpr = expr.getSubExpressions(); TreeNode[] children = new TreeNode[subExpr.length]; for (i = 0; i < subExpr.length; i++) { children[i] = new ExpressionNode(subExpr[i])); } return children; } String getStringValue(...){... } }

13 Bsp: TreeModel Interface (Java Swing) interface TreeModel { Object getRoot(); Object[] getChildren(Object node); String getStringValue(Object node, boolean selected, boolean expanded, boolean leaf, int row, boolean focus); } interface TreeGUIControl { display(); } Sehr viele Parameter, die nicht immer alle benötigt werden ! => Unnötige (, teure) Berechnungen

14 2 Konzept (Lösung der Probleme)  1. Collaboration Interface  2. Wrapper Recycling  3. Wiederverwendung und Polymorphie

15 2.1 Collaboration Interface  eine Erweiterung des Standard Interfaces  Unterteilung der Implementierung in eine bindende und eine implementierende Klasse  zwei neue Modifikatoren:  provided  expected  neues Schlüsselwort binds

16 Collaboration Interface für TreeDisplay interface TreeDisplay { provided void display(); expected TreeNode getRoot(); interface TreeNode { expected TreeNode[] getChildren(); expected String getStringValue(); provided void display(); provided boolean isSelected(); provided boolean isExpanded(); provided boolean isLeaf(); provided int row(); provided boolean hasFocus(); }

17 Die implementierende Klasse  Bietet generische Funktionalität an  Implementiert die als provided gekennzeichneten Methoden  Benutzt die als expected gekennzeichneten Methoden  Implementiert jede innere Schnittstelle

18 Bsp: Implementierende Klasse für TreeDisplay class SimpleTreeDisplay implements TreeDisplay { void display() { getRoot().display(); } class TreeNode { boolean selected;... boolean isSelected() { return selected; } void setSelected(boolean s) {selected = s;} void display() {... TreeNode c = getChildren()[i]; paint(position, c.getStringValue());... }

19 Die bindende Klasse  Bindet die generische Funktionalität an die spezielle Umgebung  Implementiert die als expected gekennzeichneten Methoden  Implementiert beliebig viele bindende Klassen für jede innere Schnittstelle  Stellt einen Konstruktor zur Verfügung

20 Beispiel: Bindende Klasse für TreeDisplay class ExpressionDisplay binds TreeDisplay { Expression root; public ExpressionDisplay(Expression rootExpr) { root = rootExpr; } TreeNode getRoot() { return ExprTreeNode(root); } class ExprTreeNode binds TreeNode { Expression e; ExprTreeNode(Expression e) { this.e=e;} TreeNode[] getChildren() { return ExprTreeNode[](e.getSubExpressions()); } String getStringValue() {return e.description();} } void anyMethod() {}

21 Konstruktoren im Collaboration Interface  Frage: Welcher der beiden Teile soll den Konstruktor enthalten ?  Antwort: Nur die bindende Klasse stellt einen Konstruktor zur Verfügung !  Dieser entspricht dem der zusammengesetzten Klasse  Begründung: Der bindende Teil stellt die Verbindung zur speziellen Anwendung dar.

22 Komposition von bindender und implementierender Klasse  Beide sind alleine nicht instanzierungsfähig  Sie müssen erst einmal wieder zusammengefügt werden  Mit Hilfe des Plus-Operators (+)  Also: class CompClass = BindClass + ImplClass; CompClass c = new CompClass(args);

23 Beispiel für die Komposition class SimpleExpressionDisplay = SimpleTreeDisplay + ExpressionDisplay;... Expression test = new Plus(new Times(5, 3), 9); TreeDisplay t = new SimpleExpressionDisplay(test); t.display();

24 Virtuelle Typen  Innere Schnittstellen von Collaboration Interfacen sind virtuelle Typen  Ihre Benutzung macht nur in ihrem speziellen Kontext Sinn => Sie sind nur im Kontext der sie umgebenden Klasse verwendbar  Vergleichbar mit Klassen-Variablen bzw. -Methoden  Frage: Ist die Typsicherheit dadurch noch gegeben ?

25 Bsp: Virtuelle Typen und Typsicherheit Expression e =...; final ExpressionDisplay ed = new SimpleExpressionDisplay(e);... // sei FileSystemDisplay eine bindende Klasse von TreeDisplay // zu einer Struktur eines Dateisystems class SimpleFileSystemDisplay = SimpleTreeDisplay + FileSystemDisplay; FileSystem fs =... ; final FileSystemDisplay fsd = new SimpleFileSystemDisplay(fs);... ed.TreeNode t = ed.getRoot(); fsd.setRoot(t); Typ-Fehler: fsd.TreeNode ist kein Untertyp von ed.TreeNode => Typsicherheit gegeben ! T A F E L

26 2.2 Wrapper Recycling  Referenzen auf bereits kreierte Objekte werden in einer Hashtabelle gespeichert  ein standard Konstruktor-Aufruf Object o = new Wrapper(arguments); wird ersetzt durch Object o = outerClass.Wrapper(arguments);  in Hashtabelle nachschauen, ob ein passendes Objekt schon existiert  Wenn ja, liefere dieses zurück  Sonst, kreiere neues Objekt und lege Referenz in der Hashtabelle ab

27 Beispiel: Wrapper Recycling class ExpressionDisplay binds TreeDisplay { Expression root; public ExpressionDisplay(Expression rootExpr) { root = rootExpr; } TreeNode getRoot() { return ExprTreeNode(root); // entspricht: // return this.ExprTreeNode(root); } class ExprTreeNode binds TreeNode { Expression e; ExprTreeNode(Expression e) { this.e=e;}... }

28 2.3 Wiederverwendung und Polymorphie  das Collaboration-Interface(CI)-Konzept unterstützt das Vererbungskonzept von Java => Erweiterungen bereits bestehender CI mit extends  Innere Schnittstellen können nicht erweitert werden  Aber: Überschreiben mit dem neuen Schlüsselwort override möglich

29 CI für einen Graphen-Datentyp interface Graph { interface Vertex { expected Edge[] getEdges(); } interface Edge { expected Vertex getV1(); expected Vertex getV2(); }

30 Erweiterte CI für Graphen-Datentyp interface ColoredGraph extends Graph { provided computeMinimumColoring(Vertex v[]); override interface Vertex { expected void setColor(int c); expected int getColor(); // aus Graph-Interface // expected Edge[] getEdges(); } override interface Edge { provided float getBadness(); } interface MatchedGraph extends Graph { provided computeMaximumMatching(Vertex v[]); override interface Edge { expected void setMatched(boolean b); expected boolean isMatched(); }

31 Hierarchisierung implementierender Klassen (1/2) class SuccessiveAugmentationColoring implements ColoredGraph { // successive augmentation coloring algorithm void computeMinimumColoring(Vertex v[]) {... } class Vertex { int temp_color; boolean isLegalColor(int color) {... } } class Edge { float badness; float getBadness() { return badness; } void setBadness(float b) { badness = b; } } class SimulatedAnnealingColoring implements ColoredGraph { // Simulated Annealing coloring algorithm void computeMinimumColoring(Vertex v[]) {...}... }

32 Hierarchisierung implementierender Klassen (2/2) abstract class AbstractColoring implements ColoredGraph { class Vertex {... } class Edge { float badness;... } } class SuccessiveAugmentationColoring extends AbstractColoring { // Successive augmentation coloring algorithm void computeMinimumColoring(Vertex v[]) {... } override class Vertex {... } } class SimulatedAnnealingColoring extends AbstractColoring { // Simulated Annealing coloring algorithm void computeMinimumColoring(Vertex v[]) {... } override class Vertex {... } }

33 Bsp: Universitätssoftware und Graphenalgorithmen

34 1.Graph: Course Collision class SchedulingGraph binds ColoredGraph { class CourseVertex binds Vertex { Course c; Edge[] cachedEdges; CourseVertex(Course c) { this.c = c; } Edge[] getEdges() {...} void setColor(int color) { c.timeSlot = color; } class CourseCollision binds Edge { Course c1,c2; CourseCollision(Course c1, Course c2) { this.c1=c1; this.c2 = c2; } Vertex getV1() { return CourseVertex(c1); } Vertex getV2() { return CourseVertex(c2); } }

35 2.Graph: Student knows Teacher class StudentKnowsTeacherGraph binds Graph { class StudVertex binds Vertex { final Student s; StudVertex(Student s) {this.s=s;}... } class TeacherVertex binds Vertex { Teacher t; TeacherVertex(Teacher t) { this.t = t; }... }... Vertex v1 = StudVertex(aStudent);...... Vertex v2 = TeacherVertex(aTeacher);... }

36 3.Graph: Student Contacts (1/2) class StudContactsGraph binds Graph { class StudVertex binds Vertex { final Student s; StudVertex(Student s) {this.s=s;} Edge[] getEdges() {... Student t =... ;... e[i] = StudContact(s,t); return e; } class StudContact binds Edge { Student s,t; StudContact(Student s, Student t) {this.s = s; this.t = t;} }

37 3.Graph: Student Contacts (2/2) class StudContactsColoredGraph extends StudContactsGraph binds ColoredGraph { override StudVertex { // expected-Methoden von ColoredGraph void setColor(int c) {...} int getColor() {...} } class StudContactsMatchedGraph extends StudContactsGraph binds MatchedGraph { override StudContact { // expected-Methoden von MatchedGraph void setMatched(boolean b) {...} boolean isMatched(){...} }

38 Polymorphie und der Plus-Operator (1/2) class SucAugSched = SuccessiveAugmentationColoring + SchedulingGraph; class SimAnSched = SimulatedAnnealingColoring + SchedulingGraph;... final SchedulingGraph sg = null; if (wantSucAug) { sg = new SucAugSched(); } else { sg = new SimAnSched(); } sg.computeMinimumColoring( sg.CourseVertex[](courses) );

39 Polymorphie und der Plus-Operator (2/2) class SucAugStudContacts = SuccessiveAugmentationColoring + StudContactsColoredGraph; class SimAnStudContacts = SimulatedAnnealingColoring + StudContactsColoredGraph; class Matching1StudContacts = MatchingAlgorithm1 + StudContactsMatchedGraph; class Matching2StudContacts = MatchingAlgorithm2 + StudContactsMatchedGraph;

40 3 Fazit  Mit heutigen Sprachkonzepten wäre die Lösung des hier beschriebenen Problems mit höherem Aufwand verbunden  Die Lösung wäre komplexer, unübersichtlicher  Das Collaboration-Interface-Konzept ist eleganter  Es unterstützt das Konzept der Wiederverwendung