Ideen aus der Diskussion zum Thema "Ist AOP/ASOC ein Paradigmenwechsel?"
Boris Bachmendo, Joachim Bayer, Pascal Costanza, Ralph Depke, Peter Werner
1. Table-Oriented Programming
Das Modell des sog. Table-Oriented Programming (http://www.geocities.com/SiliconValley/Lab/6888/top.htm)
bietet eine interessante Sicht auf die Frage, ob es sich bei AOP/ASOC um
einen Paradigmenwechsel handelt. Speziell das Konzept der Control Tables
(http://www.geocities.com/SiliconValley/Lab/6888/cntrl1.htm)
ist hier hilfreich - es geht über die Gliederungsmöglichkeiten
von Objektorientierung (Klassenhierarchie "dominiert" die Gliederung in
Prozeduren) und imperativer Programmierung (Prozeduren "dominieren" unterschiedliche
Recordtypen) hinaus. Stattdessen wird eine zweidimensionale Sicht etabliert,
in der diese beiden Gliederungen gleichberechtigte orthogonale Achsen bilden.
|
m(...) |
n(...) |
o(...) |
| C |
|
|
|
| D |
|
|
|
| E |
|
|
|
Die x-Achse beschreibt Methodensignaturen, die y-Achse Klassen und die
Zellen enthalten entsprechende Definitionen. Das Konzept der Vererbung
aus OOP ist eine effiziente Möglichkeit, mit einer Definition eine
Menge von Zellen "gleichzeitig" zu belegen, wenn die entsprechenden Klassen
sich in einer Unterklassenrelation zueinander befinden. Beispielsweise
ist eine Definition für C::m(..) gleichzeitig eine Definition für
D::m(..), wenn D eine Unterklasse von C ist:
|
m(...) |
n(...) |
o(...) |
| C |
{...} |
|
|
| D |
<<erbt von C>> |
|
|
| E |
|
|
|
Es ist leicht vorstellbar, dass zusätzliche Achsen zu einem dreidimensionalen
oder gar mehrdimensionalen Modell führen. Kandidaten für weitere
Dimensionen sind möglicherweise Produktlinien oder beispielsweise
Parametertypen, wenn eine gegebene Programmiersprache Multimethoden enthält
(z.B. Cecil, siehe http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html).
AOP/ASOC erweitert das OOP Modell dahingehend, dass über einfache
Vererbung hinaus beliebige Pfade bzw. Mengen von Zellen innerhalb eines
solchen mehrdimensionalen Modells "gleichzeitig" definiert werden können;
darüberhinaus schlagen AOP/ASOC Modelle Semantiken für die Fälle
vor, bei denen dieselbe Zelle von mehreren dieser Pfadbeschreibungen erfasst
wird.
Auf Hintergrund dieser Sichtweise stellen AOP/ASOC Modelle mindestens
ebenso ein neues Paradigma gegenüber OOP dar, wie OOP gegenüber
imperativer Programmierung.
2. Entfernung von Redundanzen
AOP/ASOC Modelle (hier sind in erster Linie Programmiersprachen gemeint)
haben sich in den letzten Jahren im wesentlichen darauf konzentriert, Features
hinzuzufügen, aber das grundlegende objektorientierte Modell unberührt
zu lassen. Die obige Sichtweise legt jedoch nahe, sich auch Gedanken darüber
zu machen, ob es evtl. Redundanzen gibt und wie diese entfernt werden könnten.
Das Vorbild hierfür sind variante Records aus imperativer Programmiersprachen,
die durch das Konzept der Vererbung in OOP subsumiert wurden. Mögliche
Kandidaten, die im Kontext von AOP/ASOC auf eine solche Redundanz hin untersucht
werden sollten, sind u.a.:
-
Vererbung: AspectJ erlaubt es beispielsweise, eine Methodendefinition
in mehrere Klassen "gleichzeitig" einzuführen ("introduction
declarations"), womit potenziell auch der Spezialfall von "traditioneller"
Vererbung beschrieben werden kann.
-
Ausnahmebehandlung: Die Tatsache, dass Exceptions in Java einem
statischen Typcheck unterworfen werden, steht in bestimmten Fällen
der Einführung von Aspekten im Weg (siehe auch http://aspectj.org/doc/faq/index.html#Q7.2).
Andererseits kann Fehlerbehandlung mit Hilfe von Aspekten ebenfalls beschrieben
werden.
-
Zugriffsrechte: Die Einschränkung des Zugriffs auf Elemente
einer Klasse (z.B. protected und private in Java) führt zu Problemen
in Zusammenhang mit Aspekten (siehe auch http://aspectj.org/doc/faq/index.html#Q6.1).
In diesem Feld sind sicherlich noch weitere Beispiele zu finden.
Pascal Costanza, 11/5/2001