Weiter: Eine Gegenüberstellung Hinauf: 18 Objekt-orientierter Entwurf Zurück: 18 Objekt-orientierter Entwurf

18.1 Objekt-orientierte Konzepte und ihre Entstehung

  

Der Begriff ,,objekt-orientiert``ist, wie so viele Konzepte in der Informatik, historisch gewachsen. Mit der Entwicklung immer komplexer werdender Computer-Systeme wuchsen auch die Möglichkeiten, Systemen immer größer werdenden Komplexitätsgrades mit Computern zu Leibe zu rücken. Dabei stellte sich heraus, daß die dazu verwendeten Hilfsmitteln, wie Entwurfsmethoden, Programmiersprachen, usw. nicht mit der Entwicklung der Hardware Schritt gehalten hatte. Dies führte zur schrittweisen Verbesserung der Werkzeuge und Programmierhilfsmittel. Man kann heute z.B. mehrere Generationen von Programmiersprachen unterscheiden. Einige typische Vertreter der einzelnen Generationen und deren wesentliche ,,Neuerungen``sind:

• Sprachen der ersten Generation (1954-1958)

  FORTRAN I mathematische Ausdrücke

  ALGOL 58 mathematische Ausdrücke

  Flowmatic mathematische Ausdrücke

  IPL V mathematische Ausdrücke

• Sprachen der zweiten Generation (1959-1961)

  FORTRAN II Unterprogramme, getrennte Übersetzbarkeit

  ALGOL 60 Block-Strukturen, Datentypen

  COBOL Datenbeschreibung, Filehandling

  Lisp Listenverarbeitung, Pointer

• Sprachen der dritten Generation (1962-1970)

  PL/1 FORTRAN + ALGOL + COBOL

  ALGOL 68 aufgeblähter Nachfolger von ALGOL 60

  Pascal einfacher Nachfolger von ALGOL 60

  Simula Klassen, Datenabstraktion

• Lücke in den Generationen (1970-1980) viele verschiedene Sprachen wurden erfunden, aber keine überdauert längere Zeit

Interessanter ist, wie die einzelnen Sprachen Daten und Programm-Code betrachten. Sprachen der ersten Generation und die frühen Sprachen der zweiten Generation zeigen eine relativ flache Struktur. Sie bestehen aus globalen Daten und Unterprogrammen, die auf diese Daten zugreifen (vgl. Abbildung 18.1). Beispiele sind typische FORTRAN- und COBOL-Programme.

 
Abbildung: Topologie von Sprachen der ersten und frühen zweiten Generation 

Bei den Sprachen der späten zweiten und frühen dritten Generation gewann der algorithmische Aspekt von Programmiersprachen überhand. Es war nun möglich, komplexe Programmstrukturen zu schaffen, aber globale Daten waren noch immer vorherrschend (vgl. Abbildung 18.2).

 
Abbildung: Topologie von Sprachen der späten zweiten und frühen dritten Generation 

Bereits mit FORTRAN II beginnend gab es getrennt übersetzbare Module, die dann fast alle Sprachen der späten dritten Generation besitzen, um das sogenannte ,,Programmieren im Großen``   (,,programming-in-the-large``)  zu ermöglichen (vgl. Abbildung 18.3). Allerdings gab es meist keine Überprüfung der Parametertypen über Modulgrenzen hinweg und keine Unterstützung für Datenabstraktion, daher konnten diesbezügliche Fehler erst zur Laufzeit des Programmes auftreten.

 
Abbildung: Topologie von Sprachen der späten dritten Generation 

Erst mit Sprachen wie Pascal wurde klar, wie ein vernünftiges Typ-Konzept aussehen kann. Diese Idee gemeinsam mit der des abstrakten Datentyps und dem Konzept des information hidings  waren die Geburtshelfer für objekt-orientierte und objekt-basierende Sprachen. Solche Sprachen fassen Daten und die dazugehörigen Operationen zu einem Gebilde zusammen. Meist wird ein solches Gebilde eine Klasse genannt. Eine typische Programmstruktur solcher Sprachen könnte für relativ kleine bis mittelgroße Anwendungen wie in Abbildung 18.4 dargestellt aussehen.

 
Abbildung: Topologie von objekt-orientierten und objekt-basierenden Sprachen für kleinere und mittelgroße Anwendungen 

Für sehr große Anwendungen (programming-in-the-colossal)  wie z.B. Betriebssysteme bedarf man neuer Sprachmitteln, die es erlauben, Gruppen von Programmeinheiten zu bilden, da Klassen und Module zu kleine Einheiten sind. Diese Art von Gruppen nennen wir Subsysteme . Ein Beispiel ist in Abbildung 18.5 gegeben.

 
Abbildung: Topologie von objekt-orientierten und objekt-basierenden Sprachen für große Anwendungen 

Wie programmiert man nun aber objekt-orientiert mit Ada? Grundsätzliche Leitgedanken sind dabei:

• Versuchen Sie, immer in abstrakten Datentypen zu denken, d.h., finden Sie heraus,
  1. was die wichtigen Objekte des Systems sind und
  2. bestimmen Sie die Operationen, die auf diesen definiert sind.
• Vermeiden Sie globale Daten!
• Verstecken Sie Entwurfsentscheidungen, die Datenstrukturen betreffen, in Paketen!

Wir wollen diese theoretischen Betrachtungen nun abschließen und im folgenden Kapitel anhand eines Beipiels sehen, wie sich ein objekt-orientierter Ansatz von anderen, herkömmlichen Entwurfsmethoden unterscheidet und welche Vorteile er gegenüber diesen besitzt. Auf genauere Details des objekt-orientierten Entwurfs gehen wir in Kapitel 18.7 ein.

Weiter: Eine Gegenüberstellung Hinauf: 18 Objekt-orientierter Entwurf Zurück: 18 Objekt-orientierter Entwurf