
\section{Vererbung: Ein "`Produzentenmechanismus"'?}
\label{HierDiffs}
Die M"oglichkeit, geerbte "offentliche Methoden aus der Schnittstelle einer
erbenden Klasse wieder zu entfernen, durchbricht das Prinzip der Erweiterung
und Spezialisierung von Konzepten im Rahmen der Implementierung einer
Klassenhierarchie\footnote{Einige Autoren halten eine Durchbrechung des Prinzips
der Spezialisierung f"ur unumg"anglich: {\it "`Von Zeit zu Zeit m"ussen Sie
aber eine Unterklasse erzeugen, die nur einen Teil der Oberklasse enth"alt,
obwohl das eine Verletzung des Prinzips von Verallgemeinerung und
Spezialisierung ist."'}  \cite{CN94}.}.
Dennoch bieten mehrere objektorientierte Programmiersprachen
diese M"oglichkeit an\footnote{Dies sind unter anderem die Sprachen C++,
Smalltalk und Eiffel.}. Bei der Entwicklung einer Klassenbibliothek ergibt sich
somit die M"oglichkeit, nur einen Teil einer Klasse zu erben. Ein anderer Teil
der Oberklasse, der eigentlich mit geerbt werden w"urde, kann aus der
Schnittstelle der Subklasse wieder entfernt werden, so als ob diese Methoden
nie geerbt worden w"aren. Dieser Vorgang kann deshalb auch als "`partielles
Erben"' bezeichnet werden.
Die Beschreibung der NIHCL zeigt, da"s von der M"oglichkeit des partiellen
Erbens bei ihrer Entwicklung umfangreich Gebrauch gemacht wurde. Im
folgenden wird beschrieben, aus welchem Grund partielles Erben in einigen
objektorientierten Programmiersprachen enthalten ist und welche Auswirkungen
die Verwendung dieser M"oglichkeiten auf die Benutzbarkeit einer
objektorientierten Bibliothek hat. 


Die Beobachtungen der bisherigen Abschnitte dieses Kapitels lassen die Frage
aufkommen, weshalb C++ als objektorientierte Programmiersprache partielles
Erben zul"a"st, obwohl diese M"oglichkeit eigentlich eine Durchbrechung
objektorientierter Prinzipien darstellt. Der Grund hierf"ur ist, da"s
Vererbung gem"a"s einer wachsenden "Ubereinkunft\footnote{\cite{Cook92}:"`Yet
there is a growing consensus that inheritance is a "`producer's mechanism"'
\cite{Mey90c} that has little to do with client's use of classes."'} in erster
Linie dem Anbieter einer Bibliothek Nutzen bringt. Diese Betrachtung l"a"st
sich in folgender These zusammenfassen:

\noindent \hspace{5mm}\underline{{\bf These:}} \newline \vspace{-7mm}
\begin{center}
  \begin{minipage}[t]{137mm}
  Der Mechanismus des Vererbens stellt in erster Linie eine Unterst"utzung des
"`Produzenten"' einer Bibliothek dar, w"ahrend die Benutzer, die
"`Konsumenten"', eine Bibliothek auf v"ollig andere Weise verwenden
\cite{Mey90c}. 
  \end{minipage}
\end{center}
Die These, Vererbung sei ein "`Produzentenmechanismus"', kann dadurch
begr"undet werden, da"s der Nutzer einer Bibliothek sich in erster Linie f"ur
die Schnittstellen der angebotenen Klassen interessiert. F"ur den Benutzer einer
Bibliothek w"are deshalb weniger wichtig, von welcher Klasse eine zu
verwendende Klasse abgeleitet wurde, sondern welche Methoden die Klasse bietet.
Der Benutzer w"urde sich also f"ur das Angebot interessieren, das ihm eine
Bibliothek macht, nicht f"ur die Art und Weise, in der dieses Angebot vom
Bibliotheksentwickler mit Hilfe der Vererbung realisiert wird. 

In den bisherigen Kapiteln wurden deutliche Hinweise darauf gefunden, da"s
Vererbung bei geschicktem Einsatz auch wesentliche Vorteile f"ur den Benutzer
einer Bibliothek bietet. Diese "Uberlegungen legen nahe, Vererbung nicht als
"'Produzentenmechanismus"' aufzufassen und f"uhren zur Gegenthese:

\noindent \hspace{5mm}\underline{{\bf Gegenthese:}} \newline \vspace{-7mm}
\begin{center}
  \begin{minipage}[t]{137mm}
Geschickt angewendet ist Vererbung eine M"oglichkeit, die "Ubersichtlichkeit
der Bibliothek zu steigern. Vererbung kann durch ihre M"oglichkeit der
Klassifizierung von Eigenschaften der Beh"alter bei der Auswahl des zu
verwendenden Beh"alters unterst"utzen. Dar"uber hinaus bietet Vererbung in Form
einer Konzept- oder Typspezialisierung eine gemeinsame Sicht auf die Objekte
verschiedener komplexer Klassen, wodurch sich der Umgang des Benutzers mit den
Klassen wesentlich vereinfacht. 
\end{minipage}
\end{center}

Die folgenden Abschnitte beschreiben die Konsequenzen der Anwendung partiellen
Erbens f"ur den Benutzer klassenorientierter Bibliotheken. Hierbei ist
besonders zu beachten, da"s partielles Erben zu einem Unterschied von
Vererbungs- und Schnittstellenhierarchie der Bibliothek f"uhrt. Beide Formen
von Hierarchien werden in den folgenden Abschnitten erl"autert.  

\subsection{Vererbungshierarchie}
Die Vererbungsstruktur einer Bibliothek ist geeignet, die Klassen zu
dokumentieren und den Benutzern beim Verst"andnis der Bibliothek zu
helfen\footnote{\cite{Cook92}: "`The inheritance structure is used to document
the classes and is presented to users as an aid to understanding the
library."'} \cite{Cook92}. In einer ohne Verwendung partiellen Erbens
entwickelten Bibliothek k"onnte der Benutzer mit Hilfe der
Vererbungsbeziehungen sehr leicht feststellen, welche
Methoden eine Klasse anbietet. In einer solchen Bibliothek bietet eine Klasse
folgende Methoden an: 
\begin{itemize}
\item Alle in der Klasse selbst definierten "offentlichen Methoden. 
\item Alle Methoden, die transitiv von von den Oberklassen der jeweiligen
Klasse als "offentlich deklariert wurden.   
\end{itemize}
Bei Verzicht auf partielles Erben ist die Vererbungsbeziehung also f"ur den
Bibliotheksentwickler genau wie f"ur den Konsumenten ein strukturierendes
Hilfsmittel. Der Nutzen der Vererbungsbeziehung f"ur den Benutzer der
Bibliothek ist noch gr"o"ser, wenn die Vererbungsbeziehungen in der Bibliothek
nicht nur zum Zwecke der Wiederverwendung von Implementierungen (Abschnitt 
\ref{Implementierungsvererbung}), sondern mit dem Ziel der Spezialisierung und
Verfeinerung von Konzepten (Abschnitt \ref{Konzeptvererbung}) eingesetzt werden.

Die Verwendung partiellen Erbens bleibt indes f"ur den Benutzer der Bibliothek
nicht ohne negative Folgen, gerade weil er sich in erster Linie f"ur das
Protokoll einer Klasse interessiert. Der Benutzer mu"s wissen, welche Methoden
in diesem Protokoll enthalten sind. Im Falle partiellen Erbens kann der
Benutzer die Schnittstelle einer Klasse nicht durch ein transitives
Zur"uckverfolgen der Vererbungsbeziehungen feststellen. Festzustellen, welche
Methoden von einer Klasse angeboten werden, ger"at zu einem komplexen
Algorithmus, bei dem eine Orientierung an der Vererbungshierarchie nur bedingt
m"oglich ist\footnote{\cite{Cook92} weist darauf hin, da"s sich besonders die
Untersuchung der in abstrakten Klassen teilweise implementierten Methoden durch
partielles Erben verkompliziert. Gerade abstrakte Klasse k"onnen aber durch ihr
Angebot einer gemeinsamen Sicht auf komplizierte Objekte bei einem Verzicht auf
partielles Erben eine Hilfe f"ur den Benutzer sein, so da"s die
Schwierigkeiten, eine Schnittstelle zu erkennen, in diesem Bereich besonders
schwerwiegend sind.} \cite{Cook92}. Partielles Erben tr"agt also selbst
wesentlich dazu bei, die Vererbung zu einem "`Produzentenmechanismus"' werden
zu lassen, da die Vorteile der Vererbung f"ur den Konsumenten ausgeschaltet
werden. 

\subsection{Schnittstellenhierarchie}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Neben dem Begriff der Vererbungshierarchie steht in Sprachen, die
partielles Erben zulassen, noch der Begriff der Protokoll- oder
Schnittstellenhierarchie\footnote{Bei einem Verzicht auf partielles Erben sind
Vererbungs- und Schnittstellenhierarchie identisch.}. Unter einer
Schnittstellenhierarchie wird die logische Organisation aller Schnittstellen
einer Bibliothek verstanden. Unter der Schnittstelle einer Klasse versteht
man die gesamte Menge der von Exemplaren dieser Klasse ausf"uhrbaren Methoden,
also die von der Klasse angebotene Funktionalit"at. Die
Schnittstellenhierarchie ist eine partielle Ordnung bez"uglich der
Konformit"at, die gemeinsame Teile von Schnittstellen in der Menge der Klassen
einer Bibliothek aufzeigt \cite{Cook92,Card84,CaMi89,BHJLC87}:

\pagebreak
\noindent \hspace{5mm}\underline{Konformit"at:}\newline \vspace{-7mm} \nopagebreak[3]
\begin{center}
  \begin{minipage}[t]{137mm}
Eine Schnittstelle B ist zu einer Schnittstelle A konform, wenn jedes Objekt,
das die Schnittstelle B anbietet, auch die Schnittstelle von A anbietet. Die
Menge der die Schnittstelle B anbietenden Objekte ist also eine Teilmenge
der die Schnittstelle A anbietenden Objekte. Betrachtet man die Schnittstellen
der beiden Klassen als Mengen von angebotenen Methoden, so stellt man fest,
da"s die speziellere Klasse B in der Regel "uber eine gr"o"sere Menge von
Methoden verf"ugt. Es sind jedoch gegen"uber der Menge der Methoden von A keine
Methoden entfernt worden. Die Menge der Methoden von A ist also eine Teilmenge
der Menge der Methoden von B. Dies bedeutet, da"s ein Objekt vom Typ B "uberall
dort verwendet werden kann, wo ein Objekt vom Typ A erwartet wird. 
\end{minipage}
\end{center}

Im Rahmen einer Untersuchung der Smalltalk-Bibliothek wurde ein
Algorithmus entworfen und implementiert, der aus den Klassen einer Bibliothek
eine Schnittstellenhierarchie extrahiert \cite{Cook92}. Abbildung
\ref{Smalltalk-Algorithmus} veranschaulicht, wie aus den einzelnen
Schnittstellen der Klassen eine Protokollhierarchie gewonnen werden kann
\cite{Cook92}. Im linken Teil des Bildes sind die von den drei Klassen A, B und
C angebotenen Methoden aufgef"uhrt. Der rechte Teil des Bildes zeigt die sich
aus diesen einzelnen Schnittstellen ergebende Protokollhierarchie. In der
Protokollhierarchie sind nur die jeweils hinzukommenden Methoden einer Klasse
angegeben. F"ur zwei Schnittstellen, die einen Teil ihres Protokolls gemeinsam
haben, f"ugt der Algorithmus eine abstrakte Schnittstelle ein. In der Abbildung
sind dies die Schnittstellen X und Y. 

\renewcommand{\epsfsize}[2]{1.0#1}
\begin{figure}[hbt]
\begin{center} 
\leavevmode
\epsfxsize=14cm
\epsffile{../Bilder/thorsten/Postscript/Smalltalk-Algorithmus.ps}
\end{center}
\caption{Entwicklung der Protokollhierarchie (nach [Cook 92])}
\label{Smalltalk-Algorithmus}
\end{figure}


Eine partiell erbende Klasse mag zwar eine gr"o"sere Menge von angebotenen
Methoden aufweisen, doch die Bedingung, da"s die Menge der Methoden der
Oberklasse eine Teilmenge der Menge der Methoden der Subklasse sein mu"s, ist
beim partiellen Erben verletzt. Partielles Erben zerst"ort also den
Zusammenhang von Vererbung und Konformit"at der Schnittstellen.


\subsection{Ergebnis}
Zusammenfassend ist festzustellen, da"s in Bibliotheken, die unter
Verwendung partiellen Erbens entwickelt werden, die Hierarchie der
Schnittstellen der Klassen unabh"angig von der Vererbungshierarchie ist.
Diese Unabh"angigkeit f"uhrt dazu, den Nutzen von Vererbung auf die Anbieter
der Bibliothek zu beschr"anken, da der Benutzer der Bibliothek die ihn
interessierende Schnittstellenhierarchie nur unter Anwendung eines komplexen
Algorithmus entwickeln kann. Die Schnittstelle einer Klasse ist nicht mehr auf
den ersten Blick zu erkennen. Oberklassen bieten dem Benutzer dann keine
einheitliche Sicht auf die Objekte komplexer Klassen.

Um beim Design einer Bibliothek diese Nachteile zu vermeiden, sollten die
Unterschiede zwischen Vererbungs- und Schnittstellenhierarchie minimiert
werden.  Beim Entwurf der Klassen sollte deshalb darauf geachtet werden, da"s
Methoden nicht zu hoch in der Bibliothek angesiedelt werden. Methoden d"urfen
erst in Klassen eingef"uhrt werden, deren Nachfolger alle ihre Methoden
implementieren k"onnen.
Die Ausf"uhrungen dieser Arbeit zeigen, da"s Vererbung kein
"`Produzentenmechanismus"' ist. Vererbung wird erst durch ihre unvorsichtige
Anwendung vom Entwickler der Bibliothek zu einem "`Produzentenmechanismus"'
degradiert. 