Wer zum ersten Mal ein objektmorientiertes Entwicklungsprojekt in Angriff nimmt, macht sich selten klar, dass er Neuland betritt. Juergen Martlmueller* schildert die Sackgassen und Irrwege, die auf unerfahrene Entwickler warten.

Weit verbreitet ist die Sichtweise, Cii sei nur besseres C und Objektorientierung im Grunde auch nichts Neues. Wer darauf vertraut, muss sehr bald eine ernuechternde Erfahrung machen: Zwar erinnert die Syntax von Cii-Code stark an C-Programme und stellen die Cii-Keywords ein Superset des C-Sprachschatzes dar; doch die Programmierstile dieser beiden Sprachen haben eigentlich nichts gemeinsam.

Verfahren und Tools

fehlen zumeist noch

Cii ist bei weitem nicht nur eine syntaktische Erweiterung von C. Das Erlernen des neuen Programmierstils kostet also seine Zeit. Es ist schwieriger, als es auf den ersten Blick aussieht, wirklich guten objektorientierten Code zu schreiben, der dann auch die der Objektorientierung nachgesagten Vorteile mit sich bringt. Zudem reicht es auf keinen Fall aus, nur eine objektorientierte Sprache zu verwenden.

Ein erstes Projekt im objektmorientierten Umfeld ist ein stetiger, muehsamer Lernprozess. Saemtliche Nachteile des neuen Denkschemas werden unmittelbar spuerbar: Es fehlt an Verfahren und Tools zur Unterstuetzung der objektorientierten Modellierung, was die Analyse und das Design erheblich erschwert.

Speicherverbrauch und

Performance-Einbu Wer mit der neuen Denkweise nicht vertraut ist, dem faellt es schwer, eine bestimmte Anwendung in Objekte aufzuteilen, da Objekte zunaechst nur statische Gebilde sind und die prozenduale Betrachtung eines Problems zuerst einmal wesentlich naeher liegt.

Ist diese Schwierigkeit ueberwunden, so kommt meist wiederum die prozedurale Sichtweise von Arbeitsablaeufen zu kurz, die es natuerlich nach wie vor gibt. Die Ursache dafuer ist, dass die Entwickler nun bestrebt sind, moeglichst alles objektmorientiert zu sehen.

Wie wichtig eine der Wirklichkeit entsprechende Modellierung der Anwendung durch Klassen und Objektzusammenhaenge ist, faellt erst dann auf, wenn aufgrund von falschen Modellen die Implementierung immer komplexer und schwieriger wird. Ein Redesign laesst sich dann oft nicht mehr vermeiden.

Objektverwaltung erscheint anfaenglich meist ueberfluessig. Als Folge davon entstehen haeufig hochdynamische Systeme: Klassen werden direkt dort instanziert, wo die entsprechenden Instanzen verwendet werden sollen. In der Folge instanzieren die Entwickler in vielen Klassen - meist schon im Konstruktor - alle benoetigten Objekte, anstatt einfache Instance-Connections ueber eine Objektverwaltung herzustellen.

Dies fuehrt zu enormem Speicherverbrauch und zu teilweise signifikanten Performance-Einbussen. In einem derartigen System sind naemlich Systemobjekte, die es eigentlich nur einmal geben muesste, in so vielen Instanzen vorhanden, wie anwendende Objekte existieren. Die Dynamik eines solchen Systems, der pulsierende Speicherbedarf, hervorgerufen durch staendiges Instanzieren und Loeschen von Objekten verschiedener Klassen, ist so gut wie nicht mehr nachvollziehbar.

Die Notwendigkeit, ueber die Verantwortung nachzudenken, einmal erschaffene Objekte auch wieder zu loeschen, wird meist unterschaetzt. So lassen sich von Neueinsteigern entwickelte objektorientierte Systeme nicht selten am staendig steigenden Hauptspeicherbedarf erkennen.

Der erste Kontakt mit dem maechtigen Instrument der Vererbung ist gepraegt von Begeisterung und Ueberschwang. Diese Einstellung bringt es mit sich, dass die Weitergabe von Eigenschaften einer Klasse an davon abgeleitete Klassen oftmals leichtsinnig erfolgt.

Sehr haeufig findet man da Klassenvererbung, wo Whole-part- Beziehungen beziehungsweise Instance- oder Message-Connections die richtige Wahl waeren, um Beziehungen zwischen Objekten auszudruecken. Nicht selten resultieren daraus Systeme und Libraries, deren Klassen samt und sonders von einer einzigen Wurzel abgeleitet sind.

Unueberschaubare

Vererbungsstrukturen

Wer davon auch nur eine einzige Klasse in einem anderen Zusammenhang wiederverwenden will, muss alle Klassen bis zurueck zur Wurzel mit uebernehmen. Die Konsequenz sind riesige Programme und Prozesse. Abgesehen davon ist es fast unmoeglich, derart komplexe Vererbungsstrukturen zu ueberblicken und zu warten.

Relationale Systeme

bedeuten Konzeptbruch

Die Integration von relationalen Datenbanken ist nur mit sehr grossem Aufwand moeglich. Eine relationale Datenbank stellt in der objektorientierten Welt einen Konzeptbruch dar: Klassen mutieren zu Tabellen, und Objekte werden zu Teilen in Tabellen demontiert.

Manchmal muss die Integration mit einer relationalen Datenbank allerdings sein. In diesem Fall ist es immer noch besser, moeglichst scharfe Grenzen der objektorientierten Welt zu ziehen, als sich diese Welt durch Konzeptbrueche und Kompromisse verwaessern zu lassen.

Problemloesung naehert

sich der Realitaet

Trotz all dieser Nachteile und Schwierigkeiten haben sich einige Entwickler - darunter der Autor - dem objektorientierten Ansatz voellig verschrieben. Die Objektorientierung wird sich durchsetzen, da sie eine realistischere und natuerlichere Sicht der Dinge erlaubt und damit eine wirklichkeitsnaehere Modellierung zulaesst.

Wenn es einen zuverlaessigen Trend in der DV gibt, dann den der stetigen Annaeherung der Problemloesungen an die erlebte Realitaet - weg von den voellig abstrakten, binaer zu programmierenden Maschinen der Vergangenheit, hin zur Abbildung der Gegenstaende der realen Welt in Objekten und Objektmodellen.

Spielregeln muessen

eingehalten werden

Um in den Genuss moeglichst aller Vorteile der objektorientierten Entwicklungen zu kommen und die Fehler der Vergangenheit nicht zu wiederholen, sollten einige organisatorische und technische Konsequenzen aus den bisherigen Erfahrungen gezogen werden:

- Wiederverwendung bekommt man nicht als Folge von Wiederverwendbarkeit geschenkt; nur wo organisatorisch sichergestellt ist, dass vorhandene Klassen wieder verwendet werden, greift der Vorteil der Wiederverwendbarkeit.

- Allgemein verwendbare Klassen muessen objektorientiert und projektunabhaengig entwickelt werden; einmal gemachte Fehler duerfen nicht wiederholt werden.

- Es sollten Spielregeln fuer die Entwicklung von Klassen und fuer die Kommunikation zwischen den Entwicklern aufgestellt werden.

Die Definition von Coding-Standards und die Schaffung einer firmenweiten Class-Library sind weitere Moeglichkeiten, die genannten Ziele zu erreichen. Es empfiehlt sich, einen Bibliothekar zu benennen, der fuer die Einhaltung der Spielregeln und fuer die Beachtung der Coding-Standards zustaendig ist.

*Juergen Martlmueller arbeitet als Produkt-Manager bei der PC i Computing GmbH in Muenchen.