Objektorientierte Komponenten Auf der Basis des Artikels „Integrating Independent Components with...

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