Upload
johannes-holst
View
215
Download
0
Embed Size (px)
Citation preview
Objektorientierte Komponenten
Auf der Basis des Artikels„Integrating Independent Components with
On-Demand Remodularization“ von M. Mezini und K. Ostermann
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
Bsp: Universitätssoftware und Graphenalgorithmen
Bsp: Universitätssoftware und Graphenalgorithmen
Übersicht
1 Einführung1.1 Motivation1.2 Problemstellung
2 Konzept2.1 Collaboration Interface2.2 Wrapper Recycling 2.3 Wiederverwendung und Polymorphie
3 Fazit
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
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(...); ...
}}
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
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 ="<"+s+">";return s;
}} Verlust der Typsicherheit
Abgewandeltes TreeModel
interface TreeModel {TreeNode getRoot();
}
interface TreeNode {TreeNode[] getChildren();String getStringValue(boolean selected, boolean expanded, boolean leaf, int row, boolean focus);
}
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
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(...){ ... }}
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
2 Konzept (Lösung der Probleme)
1. Collaboration Interface
2. Wrapper Recycling
3. Wiederverwendung und Polymorphie
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
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();
}}
Die implementierende Klasse Bietet generische Funktionalität an
Implementiert die als provided gekennzeichneten Methoden
Benutzt die als expected gekennzeichneten Methoden
Implementiert jede innere Schnittstelle
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());...
}}
}
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
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() {}
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 KlasseBegründung: Der bindende Teil stellt die Verbindung zur speziellen Anwendung dar.
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);
Beispiel für die Kompositionclass SimpleExpressionDisplay = SimpleTreeDisplay + ExpressionDisplay;...
Expression test = new Plus(new Times(5, 3), 9);
TreeDisplay t = new SimpleExpressionDisplay(test);
t.display();
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 ?
Bsp: Virtuelle Typen und Typsicherheit
Expression e = ...;final ExpressionDisplay ed = new SimpleExpressionDisplay(e);...// sei FileSystemDisplay eine bindende Klasse von TreeDisplay// zu einer Struktur eines Dateisystemsclass 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
2.2 Wrapper Recycling Referenzen auf bereits kreierte Objekte werden in einer
Hashtabelle gespeichert
ein standard Konstruktor-AufrufObject o = new Wrapper(arguments);
wird ersetzt durchObject 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
Beispiel: Wrapper Recyclingclass 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;}. . .
}
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
CI für einen Graphen-Datentyp
interface Graph {
interface Vertex {expected Edge[] getEdges();
}
interface Edge {expected Vertex getV1();expected Vertex getV2();
}
}
Erweiterte CI für Graphen-Datentypinterface 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();
}}
Hierarchisierung implementierender Klassen (1/2)
class SuccessiveAugmentationColoring implements ColoredGraph {// successive augmentation coloring algorithmvoid 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 algorithmvoid computeMinimumColoring(Vertex v[]) { ...}...
}
Hierarchisierung implementierender Klassen (2/2)
abstract class AbstractColoring implements ColoredGraph {class Vertex { ... }class Edge { float badness; ... }
}
class SuccessiveAugmentationColoring extends AbstractColoring {// Successive augmentation coloring algorithmvoid computeMinimumColoring(Vertex v[]) { ... }override class Vertex { ... }
}
class SimulatedAnnealingColoring extends AbstractColoring {// Simulated Annealing coloring algorithmvoid computeMinimumColoring(Vertex v[]) { ... }override class Vertex { ... }
}
Bsp: Universitätssoftware und Graphenalgorithmen
1.Graph: Course Collisionclass 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); }}
}
2.Graph: Student knows Teacherclass 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); ...
}
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;}
}}
3.Graph: Student Contacts (2/2)class StudContactsColoredGraph extends StudContactsGraph
binds ColoredGraph {override StudVertex {// expected-Methoden von ColoredGraphvoid setColor(int c) {...}int getColor() {...}}
}
class StudContactsMatchedGraph extends StudContactsGraphbinds MatchedGraph {override StudContact {// expected-Methoden von MatchedGraphvoid setMatched(boolean b) {...}boolean isMatched(){...}}
}
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) );
Polymorphie und der Plus-Operator (2/2)class SucAugStudContacts =
SuccessiveAugmentationColoring + StudContactsColoredGraph;
class SimAnStudContacts =SimulatedAnnealingColoring +
StudContactsColoredGraph;
class Matching1StudContacts =MatchingAlgorithm1 + StudContactsMatchedGraph;
class Matching2StudContacts =MatchingAlgorithm2 + StudContactsMatchedGraph;
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