Rainer Kröning, Berlin

Einstieg in die Objektorientierung .ppt

OO als neuer methodischer Ansatz

Ausgangspunkt für die Aktualität des Themas Objektorientierung sind die praktischen Erfahrungen, die bei

gesammelt wurden und bereits zu Beginn der 80er Jahre zur Etablierung des Begriffs objektorientierte Programmierung (OOP) führten.

Begonnen hat die Geschichte" vor über 25 Jahren /Heilmann/ :

Das Bestreben, die Paradigmen der objektorientierten Programmierung (OOP) auf die frühen Phasen des Software-Lebenszyklus zu übertragen, war methodisch fruchtbar.

Eine beachtliche Anzahl von Methoden zur objektorientierten Analyse (OOA) und zum objektorientierten Design (OOD) entstanden und entstehen immer noch, entweder

Der grundsätzliche Unterschied

In traditionellen Softwaresystemen arbeitet eine Reihe von Progammen oder Unterprogrammen auf einer Sammlung von mehr oder weniger in Beziehung stehender Daten. Dabei sind die Daten und die prozedurale Logik separate Komponenten.

Traditionelles Softwaresystem

Traditionelles Softwaresystem

Das Konzept der Datenkapselung (encapsulation) sieht eine untrennbare Zusammenfassung von Daten und Funktionen, die ausschließlich zur Manipulation dieser Daten dienen, zu einer Einheit vor.

Objektorientiertes Softwaresystem

Objektorientiertes Softwaresystem

Die Daten der Datenkapsel sind damit nur exklusiv von den dazugehörigen Funktionen, und von niemand anderem sonst, manipulierbar. Die Funktionen werden von der Datenkapsel dem Umfeld angeboten, um die Daten in der Datenkapsel lesen bzw. manipulieren zu können.

Die künstliche Trennung von Daten und Funktionen der klassischen Anwendungssysteme wird somit aufgehoben.

Die Stärken der OO-Methode

Die Stärken der Methode liegen in:

Diese Vorteile kann man erreichen, jedoch darf man nicht vergessen:

A fool with a tool is just a fool!

Konzept und Begriffe der OO-Welt

In diesem Abschnitt werden zunächst die Konzepte der Objektorientierung und die in diesem Kontext jeweils relevanten Begriffe erklärt.

Die Kenntnis und das Verständnis der Konzepte und Begriffe der OO-Welt ist die wesentliche Voraussetzung für die nachfolgend beschriebene objektorientierte Modellbildung in den jeweiligen Phasen des Prozesses der Systementwicklung.

Henderson-Sellers hat 12 Literaturquellen ausgewertet und daraus die Grundpfeiler des OO-Paradigmas extrahiert /Heilmann/:

Zusätzlich, aber nicht durchgängig, sind auch Verweise auf :

enthalten.

Heute besteht weitgehend Einigkeit darüber, welche Elemente für die Objektorientierung erforderlich sind:

Objekt

Die Einheit von Funktionen und Daten wird als Objekt (Instanz / object) bezeichnet. Objekte sind damit Ansammlungen von Daten bzw. Attributen (in einer Einheit), die auf Anstoß (Botschaften) von anderen Objekten mit der Ausführung von Funktionen bzw. Methoden reagieren.

Attribute und Methoden können öffentlich oder privat sein. Öffentliche Attribute widersprechen dem Prinzip der Datenkapselung; sie sind zu vermeiden und zum Glück in einigen Programmiersprachen (z.B. Smalltalk) verboten.

Die öffentlichen Methoden ermöglichen die Kommunikation mit dem Objekt und legen sein Verhalten fest. Die privaten Methoden tragen ebenfalls zum Verhalten des Objekts bei, die privaten Attribute beschreiben den inneren Zustand des Objekts.

Das Objekt

Das Objekt

Nachrichten

Als Nachricht (message / Botschaft) wird der Anstoß zur Ausführung einer öffentlichen Methode bei Interaktion zweier Objekte bezeichnet.

Eine Nachricht enthä einen Namen, die ihr Ziel identifiziert und, wenn erforderlich, Parameter. Sie ist vergleichbar mit einem konventionellen Funktionsaufruf.

Nachrichten zwischen Objekten

Nachrichten zwischen Objekten

Klassen

Die abstrakte, d.h. objektunabhängige Beschreibung der Eigenschaften, Strukturen und Verhaltensweisen gleichartiger Objekte erfolgt in Klassen (classes / Objekttypen / object types).

Die Klasse ist eine Schablone für Objekte. Ein Objekt wird durch Instanzbildung einer Klasse erzeugt.

Beispiele für Klassen

Beispiele für Klassen

Klassen werden definiert durch Methoden und Attribute. Attribute sind ihrerseits nur durch Methodenaufrufe manipulierbar und die Methoden binden letztendlich die Algorithmen an die Attribute.

Auf diese Art und Weise wird die Unkenntnis des Benutzers von der Implementierung der Methoden, der Struktur dieser Attribute und der Speicherrepräsentation der Attribute erreicht (informationhiding, Objekte als black-box).

Assoziation

Assoziation ist eine bidirektionale Beziehung zwischen Objekten. Die Darstellung erfolgt analog zur Entity Relationship Modellierung. Die Kardinalität definiert die Anzahl der Beziehungen.

Objekte können nur dann miteinander kommunizieren, wenn eine Assoziation zwischen ihnen definiert ist.

Beispiel für Assoziationen

Beispiel für Assoziationen

Aggregation

Die Aggregation ist eine stärkere Form der Assoziation. Es ist eine Ganzes-Teil-Beziehung (part of). Die Kardinalität gibt die jeweilige Anzahl der Teile an.

Beispiel für eine Aggregation

Beispiel für eine Aggregation

Vererbung (inheritance)

Schon die Bezeichnungen Fahrschein-Automat und Blumen-Automat erinnern daran, dass diese Klassen gemeinsame Eigenschaften haben, die vergleichbar und teilweise sogar identisch sind, wie z.B.

Es liegt deswegen nahe, die Definition eines Objekttypen als Generalisierung, d.h. Verallgemeinerung, eines / mehrer Objekttypen,
z.B. FahrscheinAutomat, BlumenAutomat --> Automat, beziehungsweise die Definition eines / mehrer Objekttypen als Spezialisierung eines Objekttypen, z.B. Automat --> FahrscheinAutomat, BlumenAutomat, abzuleiten.

Die Generalisierung (generalization) wird auch als Abstraktion (abstraction), die Spezialisierung (specialization) auch als Konkretisierung bezeichnet.

Die Generalisierung bzw. Spezialisierung führt zu einer hierarchischen Anordnung der Klassen, ggf. über mehrer Stufen, zur Klassenhierarchie oder Vererbungshierarchie.

Klassenhierarchie

Klassenhierarchie

Die in der Hierarchie höher stehende Klasse ist der Supertyp (supertype) bzw. die Oberklasse (superclass), die tiefer stehende Klasse ist der Subtyp (subtype) bzw. die Unterklasse (subclass).

In der Klassenhierarchie werden die Methoden und die Instanzvariablen der (Super-) Typen (also z.B. Automat) an die Subtypen (z.B. FahrscheinAutomat, BlumenAutomat) vererbt, d.h. sie stehen dort zur Verfügung.

In den Subtypen kann bei Bedarf eine beliebige Erweiterung der Anzahl von Methoden und / oder Attributen erfolgen. Bei Bedarf können auch die Methodeninhalte ersetzt oder modifiziert werden (Methoden-Redefinition).

Wenn eine Klasse die Eigenschaften einer Klasse erbt, dann liegt einfache Vererbung (single inheritance) vor.

Erbt eine Klasse von mehreren Klassen, dann liegt Mehrfachvererbung (multiple inheritance) oder wiederholte Vererbung vor.

Vererbung

Vererbung

Polymorphismus und Binden

Polymorphismus (polymorphism) ist die Fähigkeit einer Objektvariablen zur Laufzeit Objekte des statischen Typs der Variablen (static type) oder Objekte von Subtypen des statischen Typs der Variablen (dynamic type) beinhalten zu können.

Polymorphismus

Polymorphismus

  N J
Polymorphismus Sparbuch VarSparbuch;

VarAktien=Aktiendepot
VarSparbuch=Sparbuch.
switch Kontotyp{
case AKTIE
VarAktie.Buchen
case SPARBUCH
VarSparbuch.Buchen
}
typ Konto VarKonto;

VarKonto=Sparbuch

VarKonto.Buchen

Es wird die Methode der Klasse Konto aufgerufen.

dynamisches
Binden
typ Konto VarKonto;

VarKonto=Sparbuch

VarKonto.Buchen

Es wird die Methode der Klasse Sparbuch aufgerufen.

Polymorphismus und Bindung

Zur Laufzeit des Systems kann also in einer Objektvariablen des Typs Konto ein Objekt des Typs Sparbuch gespeichert werden. Wird dann die Methode Buchen aufgerufen, so wird, wenn kein dynamisches Binden unterstützt wird, die Methode Buchen des Typs Konto, aber nicht des Typs Sparbuch, ausgeführt.

Dynamisches Binden (dynamic binding) ist der Mechanismus, der dafür sorgt, dass die Zuordnung der konkret auszuführenden Methode beim Methodenaufruf abhängig vom dynamischen Typ der Objektvariablen erfolgt.

Wie vorher bereits beim Polymorphismus beschrieben, kann zur Laufzeit des Systems in einer Objektvariablen des Typs Konto ein Objekt des Typs Sparbuch gespeichert werden. Wird dann auf der Objektvariablen die Methode Buchen aufgerufen, so wird beim dynamischen Binden die Methode Buchen des Typs Sparbuch ausgeführt und nicht die des Typs Konto.

Terminologie und Notation

  Booch Coad
Yourdon
Jacobson Rumbaugh
Klasse class class (abstract) class class
Attribut field attribute attribute attribute
Methode operation service operation operation
Objekt object class & object object object
Subsystem class category subject subsystem subsystem,
module
Vererbung inheritance
gen-spec-struct
inherits
generalization
Aggregation has
whole-part-struct
acquaintance
association
aggregation
Assoziation association
instance
connection
acquaintance
association
association
(link)
Nachricht message
message
connection
communication
association
data flow
(event)

Terminologie und Notation

Verschiedene Sichten auf das Modell

Zur vollständigen Darstellung eines Systems reicht die Beschreibung der Objekte und ihrer Beziehungen nicht aus. Daher werden weitere Darstellungen, teilweise aus der Welt der strukturierten Analyse, zur Modellierung verwendet, so dass

Aspekte dargestellt werden können.

Die statischen Aspekte werden in Form von Klassen- bzw. Objektdiagrammen dargestellt. Aus ihnen wird ersichtlich, welche Objekte es gibt, welche Beziehung sie haben, welche Attribute und Methoden sie enthalten.

Die Dynamik wird durch Ereignisdiagramme (event trace diagram und event flow diagram) sowie durch Zustandsübergangsdiagramme (state transition diagram) deutlich gemacht.

Der funktionale Aspekt wird durch Datenflußdiagramme (data flow diagram) berücksichtigt. Hier wird dargestellt, welchen Verarbeitungen Daten unterzogen werden und in welchen Schritten die Verarbeitung abläuft.

Nicht für alle Modelle bzw. nicht für alle Teile eines Modells müssen vollständig alle Betrachtungsweisen vorliegen. Wichtig ist allein, dass das System für einen Außenstehenden verständlich ist.

Beispiel für ein Objektmodell

Beispiel für ein Objektmodell

Event Flow Diagram

Event Flow Diagram

Event Trace Diagram

Event Trace Diagram

State Transition Diagram

State Transition Diagram

Die Elemente des Zustandsübergangsdiagramms sind:

OOA: Objektorientierte Analyse

Der Prozeß der Systementwicklung

Nachdem die Konzepte und die Begriffe der Objektorientierung erklärt wurden, gilt es nun im Prozeß der Systementwicklung das vermittelte Basiswissen anzuwenden und in Anwendungssysteme umzusetzen.

Im Prozeß der Systementwicklung soll aus einem Anforderungsmodell letztendlich ein reales System entstehen. Da die OO-Vorgehensweise immer versucht, ein Abbild der Realität nachzubauen, wird versucht, die Funktionalität des zu erstellenden Systems (von Anfang an) als das Ergebnis des Zusammenspiels bzw. der Zusammenarbeit von Objekten zu sehen, zu verstehen, zu designen und zu implementieren.

Da die traditionellen Methoden ausschließlich daten- oder funktionsorientiert sind, kann von dort keine Unterstützung für die Objektorientierung erwartet werden. Nur geeignete Methoden und Techniken, die die Konzepte der OO-Welt optimal unterstützen bzw. umsetzen helfen, werden benötigt und können genutzt werden.

Um keine Strukturbrüche zwischen Analyse, Design und Implementierung zu erleben bzw. eine hohe Durchgängigkeit der Arbeitsergebnisse dieser Phasen zu erreichen, müssen die Methoden und Techniken beim Beginn einer Phase auf den Ergebnissen der Vorphase aufsetzen.

So kann das Ziel, ein einheitliches Entwicklungsparadigma im gesamten Software-Lifecycle anzuwenden, erreichbar gemacht werden, und damit letztendlich auch eine hohe Stabilität der Ergebnisse im Prozeß der Systementwicklung erreicht werden [Heilmann].

Im Rahmen des Systementwicklungsprozesses ist dabei die 2-Dimensionalität des Modells zu beachten [Booch]:

Bei der semantischen Sicht stehen die Aspekte Klassenstruktur und Objektstruktur im Vordergrund.

Die Implementierungssicht bestimmt dagegen die Modul- und Prozeßarchitektur.

Strukturierung des Systems (Problemanalyse)

Die Phase der Problemanalyse ist hier bewußt aus der Phase der Analyse herausgezogen worden, um deutlich zu machen, dass bei komplexen Systemen zunächst eine Strukturierung des Systems in überschaubaren Einheiten erfolgen muß, um einen angemessenen Ausgangspunkt, nämlich ein Anforderungsmodell, für die nachfolgenden Phasen zu haben.

Ziel dieser Phase ist es, ein Anforderungsmodell zu erstellen, welches das System in überschauberen Einheiten beschreibt.

Bei der Problemanalyse sind folgende Fragen zu beantworten :

Bei der Beschreibung sind folgende Punkte zu beachten :

Die Problemanalyse vollzieht sich in folgenden, teilweise parallelen, Schritten:

Objektorientierte Analyse (OOA)

Bei der objektorientierten Analyse sind die Anworten auf die Fragen der Problemanalyse weiter zu verfeinern. Ein tiefergehendes Fachverständnis ist aufzubauen, um die Objekte des Anwendungsbereiches und deren Beziehungen zueinander aufzudecken.

Alle Aussagen zum Problembereich sind zu sammeln und zu ordnen, wobei die DV-technische Umsetzbarkeit in keinem Falle zu beachten ist. Das Ergebnis sollte allgemein und nicht ausschließlich auf den Problembereich zugeschnitten sein
/Heilmann/, um die Wiederverwendbarkeit, als einen entscheidenden Aspekt der Objektorientierung, von Anfang an zu berücksichtigen.

Ziel ist die Beschreibung des Systems mit Objekten (incl. Methoden und Attributen) durch Verfeinerung der logischen Sicht auf die Teilsysteme der Systemstruktur, damit aus dem Anforderungsmodell das Funktionsmodell entwickelt werden kann. In GRAPES wird das Funktionsmodell in ein Fach-Grobmodell (Ergebnis der fachlichen Aufgabendefinition der Phase A20) und ein Fach-Feinmodell (Ergebnis der fachlichen Lösungsdefinition) getrennt.

Bei der Objekt- und Methodenfahndung (Schimanksi-OO) sind folgende Punkte zu beachten :

bei der statischen Sicht sind folgende Aspekte zu beachten und festzuhalten:

Beispiel einer OOA nach Rumbaugh

Beispiel einer OOA nach Rumbaugh

OOD: Objektorientiertes Design

Beim objektorientierten Design sind folgende Fragen zu beantworten:

Durch die Beantwortung dieser Fragen wird das Ziel, nämlich das Design des zu realisierenden Modells, erreicht und somit aus dem Funktionsmodell das Realisierungsmodell abgeleitet.

Die DV-technische Umsetzbarkeit der OOA-Ergebnisse wird von nun an mitbeachtet und fließt in das Realisierungsmodell mit ein.

Der Grundgedanke beim Design ist die Abbildung der Fachwelt (Ereignisse lösen Aktivitäten aus) auf die DV-Welt (Ereignisse lösen Botschaften aus, die Methoden auf Objekten anstoßen).

Zusätzlich werden die Abstraktion, die Generalisierung und die Aggregation als Umsetzungsprinzipien für die Festlegung der Objekttypen und der Vererbungshierarchie genutzt.

Durch Abstraktion werden aus Objekten Klassen gewonnen, wobei die statische Abstraktion auf der Ebene der Attribute und deren Strukturen sowie den Methoden erfolgt.

Generalisierung (is_like_a) bedeutet die Zusammenfassung gemeinsamer Eigenschaften in Supertypen unter Beachtung

Durch Generalisierung werden also aus Objekttypen die Supertypen abgeleitet.

Durch Spezialisierung (is_kind_of) werden aus Objekttypen die Subtypen abgeleitet.

Durch Analogien (is_analogous_of) werden weitere Subtypen von einem (gemeinsamen) Supertypen abgeleitet.

Ein Entwurfskriterium von Objekttypen muß auch der Aspekt der Wiederverwendbarkeit von Objekttypen sein. Je allgemeiner Objekttypen definiert werden, desto eher sind sie in einem anderen Kontext wiederverwendbar.

Die Klassifizierung bzw. die Typisierung der Objekte durch Abstraktion, Generalisierung und Aggregation sollte zu einem einfachen und übersichtlichen Modell der Objekttypen führen (Architekturplan).

Dieser implementierungsunabhängige Architekturplan beschreibt, wie die OOA-Ergebnisse realisiert werden können. Im Zentrum des Architekturplanes steht das Vererbunskonzept und damit die (maximale) Wiederverwendung bestehender Klassen. Wenn neue Klassen zur Realisierung erforderlich sind, müssen diese nachträglich im Architekturplan aufgenommen werden.

Die relevanten Zustandsgrößen und Wechselwirkungen sind, entsprechend der Komplexität, angemessen zu dokumentieren.

Das Realisierungsmodell sollte folgende Dokumentationen umfassen:

Object Modelling Technique (OMT) nach Rumbaugh

Eine vollständige Systembeschreibung nach der Object Modelling Technique (OMT) von /Rumbaugh u.a/] z.B. umfaßtdrei Modelle:

Die Aufteilung eines Systems aus diesen drei Sichten führt zu eigenständigen, aber nicht generell unabhängigen, Modellen. D.h., es gibt in jedem Modell immer Beziehungen zu den beiden anderen Modellen, jedoch immer eindeutig begrenzt und explizit genannt.

Das Objektmodell definiert und beschreibt die:

Die Darstellung des OM erfolgt in:

Struktur eines Klassendiagramms (class diagram)

Struktur eines Klassendiagramms (class diagram)

Beispiel eines Klassendiagramms

Beispiel eines Klassendiagramms

Beispiele Instanzendiagramme (instance diagram)ks

Beispiele Instanzendiagramme (instance diagram)

Beispiele einer Vererbungshierarchie (instance hierarchy)

Beispiele einer Vererbungshierarchie (instance hierarchy)

Klassendiagramm mit Assoziationen und Links

Klassendiagramm mit Assoziationen und Links

Instanzendiagramm mit Assoziationen und Links

Instanzendiagramm mit Assoziationen und Links

Das Dynamikmodell definiert und beschreibt die Kontrollstrukturen für Objekte (mit Ereignissen und Zuständen über die Zeit) und die Entscheidungen, die abhängig von den OM-Datenwerten, FM-Aktionen benutzt, um OM-Datenwerte zu verändern.

Ein Ereignis wird dabei verstanden als ein Signal, welches zu einem bestimmten Zeitpunkt gegeben wird, dass etwas Bestimmtes passiert ist. Die Änderung eines Zustandes erfolgt immer durch ein entsprechendes Ereignis (Transition = Übergang).

Die Darstellung des DM erfolgt im Statusdiagramm (state diagram) mit Zuständen, Ereignissen und Verweisen auf Objekte (OM) und Funktionen (FM).

Statusdiagramm (state diagram)

Statusdiagramm (state diagram)

Das Funktionsmodell definiert und beschreibt die notwendigen Funktionen für Werteveränderungen von Daten mit Abbildungsvorschriften, Bedingungen und Abhängigkeiten, und die Aktionen, die von Methoden (OM) und Aktionen (DM) angestoßen werden müssen, um mit den OM-Daten zu arbeiten.

Die Darstellung erfolgt im Datenflußdiagramm (data flow diagram) mit Werteabhängigkeiten, Umrechnung von Eingabe- in Ausgabewerten und Funktionen.

Prozeßnotation

Prozeßnotation

Datenfluss zwischen Prozessen

Datenfluss zwischen Prozessen

Aktionsobjekte, die Daten konsumieren und/oder produzieren

Aktionsobjekte, die Daten konsumieren und/oder produzieren

OOP: Objektorientierte Programmierung

Ziel der Phase objektorientierte Implementierung, auch OO-Programmierung im weiteren Sinne (OOP) genannt, ist die Implementierung des Realisierungsmodells als ein reales System.

Es werden die OOD-Ergebnisse auf einer bestimmten Systemsoftwarebasis realisiert, d.h. die in der vorherigen Phase designten Klassen und deren Beziehungen werden in Quellcode umgesetzt. Jetzt erfolgt die Codierung der Objekttypen mit ihren Interfaces und Bodies.

Bei der OOP sind folgende Fragen zu beantworten:

Wird die klassische Dreiteilung konventioneller Informationssysteme betrachtet, dann erhä man drei Klassen von OO-Implementierungswerkzeugen:

Objektorientierte Benutzerschnittstellen-Werkzeuge sollten nicht nur den statischen Aufbau von Benutzerschnittstellen durch Fenster, Menues, Buttons, etc. berücksichtigen, sondern auch dynamische Aspekte wie Vorgänge oder Datenschutz, die letztendlich erst ein koordiniertes und kontrolliertes Zusammenspiel der Benutzer mit dem System erlauben.

Objektorientierte Programmierumgebungen sollten mindestens eine OO-Sprache, einen Compiler, einen Editor, einen Binder/Lader, einen Klassenverwalter und Testtools bereitstellen.

Die gängigsten Sprachen stehen heute auf den Betriebssystemen MS-Windows, OS/2 und UNIX zur Verfügung.

Objektorientierte Datenbankmanagementsysteme sind in Arbeit, als Prototypen am Markt verfügbar und erreichen immer mehr den Produktstatus.

inkrementelle Softwareentwicklung?

Systeme werden in Form von Zusammenarbeit von Objekten realisiert. Es kann unterstellt werden, dass z.B. das Aufnehmen eines neuen Objekttypen in die Anwendung recht unproblematisch erfolgen kann. Eine inkrementelle Softwareentwicklung wird dadurch umso eher möglich.

iterative Vorgehensweise?

Wenn die inkrementelle Softwareentwicklung durch OO unterstützt wird, dann wird auch ein iteratives Vorgehen ermöglicht. Das Ein- und Ausbauen von Objekttypen in die Anwendung zum Test des Designs, der Funktionalität etc. ist wiederholt möglich. Auch partielle Re-Designs der Anwendung werden möglich, denn die Objekttypen an sich behalten ihre Eigenschaften, weil z.B. nur die Koordination des Zusammenspiels der Objekttypen geändert werden muß.

Wiederverwendung von Software?

Softwaretechnische Abbildungen der Realität, sprich Objekttypen, sind in einem anderen Kontext eher wiederverwendbar als Datenstrukturen mit gestreut realisierten Funktionen zur Manipulation dieser Daten.

Objekttypen, im Sinne von Software-ICs, werden in die neue Anwendung gesteckt und ihre Methoden vom neuen Anwendungsumfeld aufgerufen.

Durch die entsprechende Klassenbibliothek wird die Wiederverwendung noch mehr erleichtert.

offene, erweiterbare Systeme?

Objekttypen, im Sinne von Software-ICs, bieten extensiv die Möglichkeit, Systeme leichter erweitern zu können. Damit sind OO-Softwaresysteme generell offen, andere Software-ICs aufzunehmen, um damit zum erforderlichen Zeitpunkt die neuen Eigenschaften des Objekttypen im Kontext der alten Anwendung nutzen zu können.

Erhöhung der Entwicklungsproduktivität?

Die Mehrfachentwicklung kann durch die Wiederverwendung vermieden werden. Insgesamt wird dadurch auch die Wirtschaftlichkeit des Entwicklungsprozesses gesteigert.

Verbesserung der Produktqualität?

Die Wiederverwendung bedeutet den Einsatz bereits ausgetesteter Komponenten. Somit kann von weniger Fehlern beim Einsatz des Softwareproduktes insgesamt ausgegangen werden, wenn die Wiederverwendung umfangreich genutzt wurde.

Reduzierung der Komplexität?

Das Klassenkonzept führt zu überschauberen Codeblöcken in den Objekttypen, da durch die Vererbung eine geringe Komplexität der Klassen erreicht werden kann / sollte.

wartungsfreundlicher?

Die potentiellen Fehlerquellen werden durch die Vererbung zusätzlich reduziert und damit auch letztendlich eine vereinfachte und schnellere Wartung ermöglicht.

geringerer Codeumfang?

Mächtige Systemklassen bzw. Klassenbibliotheken erleichtern bzw. reduzieren die Arbeit.

Weisheit

555

Mark Twain
1835 – 1910
amerikanischer Schriftsteller

Musikerwitz

Ein Bratscher geht in die Kneipe und bestellt etwas zu trinken.
"Was darf es denn sein, ein Viertel oder ein Halbes?" fragt der Kellner.
"Ein Halbes bitte, eine Viertel ist mir zu schnell."