1
Download Konzeptionelle und technische Weiterentwicklung eines
Transcript
Seite 74 Kapitel 4 - Frameworks für WAM jeweils eigene Klassen ableiten mußte. Zu implementieren waren jene Methoden, die Objekte in die Liste einfügten bzw. wieder herausgaben: beide Methoden benutzten dieselbe Klasse, der wegen Implementation mit void-Pointern notwendige Type-Cast war also sicher. Der Benutzer dieser Listen mußte immer selbst eigene Klassen implementieren, andere Behälterkonzepte fehlten in diesem Stand des WAM-Frameworks (vgl. [Riehle93]). Mit den Templates in C++ entstand der Wunsch nach „besseren“ Behältern, die nun technisch möglich wurden. [Traub95] stellte fest, daß Implementationsvererbung für Behälterklassen Bibliotheken dominiert, daß heißt z.B. die Ableitung einer sortierten Liste von einer Liste (dabei geht die Listeneigenschaft verloren, an beliebiger Position einfügen zu können). Die ConLib folgt mit ihrer Hierarchie einer echten Klassifikation nach Behälterkonzepten (siehe Abbildung 4-2). Der Benutzer entscheidet sich für das gewünschte Konzept, einzig an der Stelle der Erzeugung eines Behälters wählt er die Implementationsform - z.B. ein dynamisches Array mit schnellem Zugriff aber aufwendigerem Löschen und Einfügen, oder eine Double-Linked-List mit erhöhtem Platzbedarf. Bezeichner und Schnittstellenparameter sollten statisch vom Typ einer möglichst abstrakten Oberklasse deklariert sein. Klassenhierachie, Vererbung von links nach rechts tUOrdTable tTable tStack tContainer tQueue tArray tOrdTable tDQueue tUOrdCol tCollection 1. Klassifikation nach Zugriffsmethode tOrdCol 2. Ordnung ? tDictionary tIntOrdTable tSortedTable tExtOrdTable tAssocList tBag tSet Duplikate ? tIntOrdCol tSList tExtOrdCol tList 3. Art der Ordnung Abbildung 4 - 2: Behälter - Klassifikation der ConLib Vergleichbar den robusten ET++ Iteratoren enthält die ConLib ein Konzept stabiler Cursors (zu den Begriffen vgl. [Traub95]), die in beliebiger Anzahl auf einem Behälter arbeiten und auch bei Änderung dessen Inhaltes in einem definierten Zustand bleiben. Die ET++ erreicht dies z.B. durch den Trick „verzögertes Löschen“ (Elemente bleiben erhalten, bis kein Iterator mehr auf sie zeigt) nur scheinbar, da die Semantik teilweise vorhandenen Elemente fraglich ist. Statt dessen erfaßt die ConLib den Sonderfall explizit im Zustandsmodell der CursorKlasse, im Anwendungsprogramm kann dies sicher behandelt werden. Zur Implementation der Behälterkonzepte verwendet [Traub95] nur drei tatsächliche, höchst effiziente Behälter, deren aufwendige interne Struktur dem Benutzer vollständig verborgen bleibt. Mit der STL wird die ConLib nicht überflüssig, da deren Konzepte der STL überlegen sind. Denkbar wäre ein Austausch der genannten drei tatsächlichen Behälter als technische Basis der Bibliothek durch eine Abbildung auf die STL.
