Dieser Betrag setzt sich mit den Zielen der Objektorientierung auseinander und geht der Frage nach, inwiefern diese Ziele wirklich erreicht wurden. Die ersten Protagonisten der Objekttechnologie haben sich sehr hohe Ziele gesetzt. Ziele, die nur begrenzt messbar sind. Sie wollten die Produktivität um ein Vielfaches steigern, die Wartungskosten auf nahezu Null reduzieren, die Wiederverwendung fördern und die Portabilität der Software sichern. Wie etliche empirische Studien nachgewiesen haben, sind diese Ziele nur zum Teil erreicht worden. Wie alle IT-Technologien war auch die Objekttechnologie „oversold“. Dennoch hat sie auch viele positive Einflüsse auf die Softwareentwicklung gehabt, vor allem auf die Wiederverwendung und die Portierbarkeit- es hat sich letzten Endes gelohnt, in diese Richtung zu gehen. Doch damit dürfen wir uns jetzt nicht zufriedengeben. Die Suche nach dem Heiligen Gral der Softwareentwicklung geht weiter.
Wenn wir uns ein Urteil über den Erfolg der Objekttechnologie bilden wollen, müssen wir die Technologie an ihren eigenen Zielen messen. Die wichtigsten Argumente für die Einführung objektorientierter Methoden und Programmiersprachen sind laut den ersten Protagonisten der Bewegung
Der vorliegende Beitrag setzt sich mit diesen vier Zielen auseinander und prüft, inwiefern die Objekttechnologie – gemeint sind OO-Analyse, OO-Design, OO-Programmierung und OO-Test – dem jeweiligen Ziel näher gekommen ist. Hat Objektorientierung gebracht, was sie versprochen hat? Am Ende, nachdem wir jedes dieser Ziele untersucht haben, kommen wir auf diese Frage zurück und versuchen, eine Antwort zu geben.
Laut Tom Love, Gründer der Productivity Products International Corporation, sollte die Objektorientierung eine größere Produktivitätssteigerung mit sich bringen. Er schrieb in der Zeitschrift Datamation im Mai 1987:
„Structured programming was only a small help. It provided only 10-15 % improvements of 10 to 15 times … Object oriented programming stands ready to provide such needed improvements because it offers a radically different, more intuitive way of conceptualizing and building systems …” Auf der ersten OOPSLA-Konferenz in Portland, Oregon im Jahre 1986 erschienen mehr als 1000 Anhänger der neuen OO-Entwicklungsmethode. Alle waren fest davon überzeugt, sie würde eine Revolution in der Softwareentwicklung mit sich bringen. Alle Probleme, mit denen die Entwickler sich jahrelang herumgeplagt hatten, würden sich in Luft auflösen. Es wird möglich sein, mühelos von der Analyse der Anforderungen über den Entwurf der Architektur bis zur Erstellung des Codes hindurch zu gelangen. Die alten semantischen Barrieren zwischen den Abstraktionsebenen würden verschwinden. Der Durchgang von den Anforderungen bis zum Code würde nicht nur wesentlich schneller erfolgen, der produzierte Code würde viel weniger Fehler enthalten als bisher, und das bedeutet weniger Testaufwand. Davon waren führende Softwaretechnologen jener Zeit überzeugt.
Einer der stärksten Befürworter der Objekttechnologie war David Thomas von der Carleton Universität in Kanada. Er war an der Entwicklung der Sprache Smalltalk beteiligt und überzeugt, dass Objektorientierung eine signifikante Steigerung der Softwareproduktivität bringen würde. Er schrieb:
„We have been convinced since 1975 that the object-oriented approach to software development is the best of all known techniques. It will revolutionize programming.”
Durch die Vereinigung der Daten mit den Prozeduren, die sie verarbeiten, würden all die Probleme, die sich aus der Trennung der Daten von den Algorithmen ergeben, verschwinden. Ergo ließen sich komplexe Systeme viel leichter aus den kombinierten Bausteinen (Data + Algorithm) konstruieren. Der Entwickler hat auch mehr Kombinationsmöglichkeiten. Die Trennung der Daten von den Prozeduren war laut Tom Love einer der größten produktivitätshemmenden Faktoren in der bisherigen Softwareentwicklung. Sie zu beseitigen, war ein großer Verdienst der Objekttechnologie. Die Kapselung der Daten und Funktionen in selbstständigen Objekten erlaubt es, diese Objekte auszulösen und zu versetzen. Die Objekte reagieren nur auf Meldungen beziehungsweise Botschaften von außen. Sie erhalten vordefinierte Aufträge und liefern vereinbarte Ergebnisse. Wie die Ergebnisse zusammenkommen, bleibt nach außen verborgen – Information Hiding. Somit haben externe Prozeduren keinen Zugang zu den gekapselten Daten und Funktionen, sondern haben stattdessen eine wohldefinierte Schnittstelle, in der der Datenaustausch geregelt ist. Diese Eigenschaft ermöglicht die Zusammenstellung großer Systeme aus vielen winzigen Bausteinen. Wenn ein Großteil der Bausteine vorgefertigt ist, entfällt ein entsprechender Großteil des Entwicklungsaufwandes.
Ein weiterer produktivitätstreibender Faktor ist die Vererbung. Es werden sowohl Daten als auch Funktionen auf einer höheren Abstraktionsebene programmiert und an die unteren Ebenen weitergegeben, wo sie auch modifiziert werden können. Dies erspart den Entwicklern der untergeordneten Codeeinheiten den Aufwand, diese Daten und Funktionen von Grund auf zu programmieren.
Diese redundante Kodierung war ein weiterer produktivitätshemmender Faktor in der bisherigen strukturierten Softwareentwicklung. Mehr als 50 Prozent des Codes war redundant. Die Entwickler haben den Code kopiert und nur wenige Zeilen geändert. Mit Vererbung konnten sie nun den originalen Code übernehmen, ohne ihn versetzen und verändern zu müssen. Rebecca Wirfs-Brock schreibt dazu:
_„You don’t destroy the original code, you just extend it and build upon it… Inheritance makes it possible to define complex new objects without the bother of writing everything from scratch.“
Zu diesen produktivitätssteigernden Eigenschaften der objektorientierten Programmierung kommt die Flexibilität durch Polymorphie dazu. Die Kopplung der Module in den prozeduralen Systemen war in der Regel sehr starr. Es war statisch festgelegt, welches Modul welche anderen Module aufruft. Es gab sogar einen speziellen Linklauf, um die Module fest aneinander zu einer Run-Unit zu binden. Das hieß, wenn der Entwickler eine andere Modulkombination haben wollte, musste er eine andere Run-Unit zusammenstellen.
Es gab zwar in COBOL sowie in PL/I dynamische Aufrufe, aber diese wurden nur selten benutzt, weil die Handhabe umständlich und undurchsichtig war. Man musste alle potenziell aufrufbaren Module zusammenbinden, um zur Laufzeit zu bestimmen, welches Modul als Nächstes tatsächlich aufgerufen wird.
In den objektorientierten Sprachen ist es viel einfacher, die gewünschte Methode durch ihre Klasse zu identifizieren, und zwar zur Kompilierzeit. Das macht den Code viel flexibler und erlaubt mehr Bindungskombinationen. Diese Eigenschaft ist zwar umstritten, aber sie hat ihre Vorteile: ein Code mit tief verschachtelten Fallanweisungen kann durch die Nutzung polymorpher Aufrufe vereinfacht werden.
Hat die Objekttechnologie tatsächlich zu einer Produktivitätssteigerung in der Entwicklung geführt? Diese Frage kann nicht eindeutig beantwortet werden. Es gibt sowohl positive als auch negative Berichte.
Auf der positiven Seite steht, dass grafische Oberflächen, wie das Multimedia Spreadsheet von Rank Xerox für die U.S. CIA und das IBM Timesharing System TPF2 ohne Objekttechnologie gar nicht möglich gewesen wären. Ann Hardy von Key Logic behauptet:
„The TPF2 software has been written in an object oriented version of PL/I. We could not have built the system without it.”
Das Gleiche gilt für Apples Lisa und Macintosh. Beide Produkte wäre ohne die neue Entwicklungstechnologie schwer möglich gewesen. Diese Feststellung unterstreicht die Tatsache, dass für manche Anwendungstypen die Objekttechnologie alternativlos ist. Auch in anderen Anwendungsbereichen, wie Telekommunikation und Multimedia, ist die Objektorientierung unverzichtbar. Keiner käme auf die Idee es anders zu machen, es sei denn in einer noch fortschrittlicheren Form der Programmierung wie Aspektorientierte Programmierung.
Doch auch im klassischen Datenverarbeitungsbereich gibt es genug Erfolgsgeschichten, was die Produktivität angeht. Durch die Verwendung von C# im Zusammenhang mit einem .Net-Rahmen konnte ein Automobilzulieferer eine Produktivitätssteigerung von 200 Prozent erreichen, vor allem durch die Verwendung vorgefertigter Bausteine. Ähnliche Produktivitätssteigerungen sind in Java-Projekten erreicht worden, zum Beispiel bei der Sparkasseninformatik in der Entwicklung neuer Buchungssysteme oder bei der Allianz Versicherung in der Ablösung alter Inkassosysteme.
Diese Erfolgsgeschichten sprechen für sich. Objekttechnologie kann, wenn richtig angewandt, Produktivität steigern und die Entwicklung beschleunigen. Kritische Stimmen kommen am Ende des Artikels zu Wort.
Noch mehr als die Steigerung der Produktivität hatte die Objekttechnologie die Senkung der Wartungskosten als Ziel. Während der Achtzigerjahre sind die Kosten für die Erhaltung bestehender Systeme immer weiter gewachsen und machten bis zum Ende des Jahrzehnts mehr als zwei Drittel der Gesamtkosten aus: die Kosten für die Wartung und Weiterentwicklung der alten Systeme waren doppelt so hoch als die Kosten für die Entwicklung neuer Systeme.
Es wurde von den Vertretern der Objekttechnologie behauptet, dies sei vorwiegend eine Folge der prozeduralen Programmierung. Die Programme sind zu groß und zu komplex geworden. Außerdem litt die Wartung an der schlechten Qualität des Codes, der nur mit großer Mühe zu verstehen war. Mit der Einführung der Objektorientierung im Entwurf sowie in der Programmierung sollte alles besser werden. Die Wartungskosten sollten um die Hälfte reduziert werden.
Software hat drei Dimensionen – Größe, Komplexität und Qualität. Die Wartbarkeit eines Softwaresystems wird von diesen drei Größen bestimmt. Die neue Objekttechnologie versprach, die Größe und Komplexität der Softwaresysteme zu reduzieren und die Qualität zu steigern. Dadurch sollten die Wartungskosten zurückgehen.
Schon allein die Behauptung, dass Wartungsaufwand von den Eigenschaften der Software selbst abhängt, war falsch. Wartungsaufwand hängt von verschiedenen Faktoren ab, unter anderem von der Wartungsumgebung, von den Fähigkeiten des Wartungspersonals und von den Werkzeugen, die das Personal zur Verfügung hat. Demnach kann die Veränderung der Software nur einen begrenzten Einfluss auf die Wartungskosten haben.
Beginnen wir mit der Größe. Prozedurale Systeme waren in der Tat zu groß, vor allem waren die Bausteine zu groß geraten. Je größer die Bausteine – Module und Prozeduren – umso schwieriger ist es, sie zu verstehen. Hauptursache für die übertriebene Größe der prozeduralen Systeme war die „Copy & Paste“-Technik. Programmierer haben große Codeabschnitte von einem Modul zum anderen versetzt und dabei nur wenige Zeilen geändert. So wurde der Code früher wiederverwendet. Änderungen müssten jedoch an vielen Stellen eingebaut werden. Statt neue Subroutinen zu schaffen, haben Entwickler den Code an Ort und Stelle erweitert, wodurch er immer größer geworden ist. Mit Hilfe der Vererbungstechnik und der Schaffung kleiner, wiederverwendbarer Klassen konnte die Objekttechnologie die Codemenge erheblich reduzieren, jedoch auf Kosten der Komplexität.
Komplexität wird von der Anzahl der Beziehungen zwischen den Codebausteinen bestimmt. Die Objekttechnologie reduziert zwar die Größe der einzelnen Bausteine, beziehungsweise der Prozeduren, aber sie schafft dafür mehr Bausteine. Richtige OOSysteme bestehen aus einer Vielzahl kleiner Klassen, jede mit einer begrenzten Zahl an Daten und Funktionen. Allein die Verwaltung der vielen Source-Bausteine verursacht einen großen Aufwand. Was aber viel mehr wiegt ist die hohe Anzahl der Beziehungen zwischen den Bausteinen. Jede Vererbung, jede Assoziation ist eine Beziehung, beziehungsweise eine weitere Abhängigkeit. Je mehr Beziehungen zwischen den Systembausteinen, umso höher die Systemkomplexität. Hinzu kommt die Abhängigkeit von den anderen Entwicklern. Der Entwickler einer Klasse, die von einer anderen Klasse erbt und die eine andere Klasse benutzt, ist abhängig von dem Entwickler jener Klasse. Wenn dieser Entwickler ausfällt – aus welchen Gründen auch immer – muss der abhängige Entwickler seinen Code übernehmen. Einer der Autoren hat in einem Projekt gearbeitet, in dem die reine Objektorientierung aus diesem Grund aufgegeben wurde. Wir können daraus schließen, dass die OOSysteme zwar kleiner, aber aufgrund der vielen Beziehungen komplexer geworden sind. Mit der Objekttechnologie wurde der Teufel mit dem Beelzebub vertrieben.
Was die Qualität betrifft ist es schwer, eine Verbesserung nachzuweisen. Die vielen GoTo-Verzweigungen sind verschwunden, dies ist aber nicht eindeutig ein Verdienst der Objekttechnologie, das hat die strukturierte Programmierung geschafft. Die Kohäsion der Module, beziehungsweise der Zusammenhang der internen Funktionen, ist gewachsen, aber ebenso die Kopplung beziehungsweise die Abhängigkeit interner Funktionen von externen Funktionen. Man kann behaupten, die Bausteine sind kleiner geworden, dafür wurde die Zahl der Abhängigkeiten umso größer.
Es gibt auch qualitativ hochwertige prozedurale Systeme. Qualität ist also nicht zwangsläufig mit der Programmiertechnik verbunden. Sie folgt aus der richtigen Verwendung der jeweiligen Technik, egal ob strukturiert oder objektorientiert. Nichts ist schlimmer als die falsche Anwendung der Objekttechnik, weil sie nicht richtig verstanden wurde.
Die Behauptung der Befürworter der Objekttechnologie, diese würde die Wartungskosten um 30 bis 50 Prozent reduzieren, wurde nie bestätigt, obwohl viele Forscher es versucht haben.
Eine der ersten Untersuchungen wurde von Professor Norman Wilde von der Universität West Florida bereits im Jahre 1993 durchgeführt. Er benutzte dazu ein C++-System von der Belcore Corporation. Zum einen hat sein Team den Quellcode mit Werkzeugen analysiert und gemessen, zum anderen führte es Interviews mit dem verantwortlichen Wartungspersonal durch.
Es stellte sich dabei heraus, dass einige der viel gelobten Eigenschaften der OO-Programmierung negative Konsequenzen für die Wartung hatten, vor allem die Vererbung, wenn diese über eine bestimmte Tiefe hinausgeht. Ein weiteres Problem ergab sich aus der Vielzahl von Interaktionen zwischen Methoden in verschiedenen Klassen. Ein drittes Problem verursachte die dynamische Bindung mit Polymorphie. Der Code gewinnt dadurch an Flexibilität, wird jedoch auch schwer nachvollziehbar. Der durchschnittliche Entwickler kommt damit nicht zurecht und trifft Fehlentscheidungen bei Codeänderungen, die zu schwer auffindbaren Fehlern führen.
Nicht zuletzt hatte Belcore mit den neuen objektorientierten Systemen mehr Fehler zu korrigieren als bisher mit den alten prozeduralen Systemen. Obendrein sank die Performanz der Systeme. Die Laufzeiten der neuen C++-Systeme stiegen um 45 Prozent gegenüber den alten C-Systemen. Ergebnis dieser Studie war, dass die Objektorientierung einige Vorteile, aber ebenso schwerwiegende Nachteile mit sich bringt. Ausschlaggebend für die Wartbarkeit der OO-Programme waren die Tiefe der Klassenhierarchie, die Anzahl der Assoziationen und der Gebrauch polymorpher Bindungen. Das hieß, je mehr objektorientiert gearbeitet wurde desto höher die Wartungsaufwände.
Eine weitere Studie zur Wartbarkeit fand an der Universität Wisconsin im Jahre 2007 statt, dieses Mal mit Java-Programmen. Ein Forscherteam unter Professor Michael Eierman ist der Frage nach der Überlegenheit objektorientierter Systeme bezüglich der Wartbarkeit nachgegangen. Zwecks des Vergleichs haben sie Wartung als einen Sammelbegriff für Fehlerkorrekturen, funktionale Erweiterungen, Änderungen und Refakturierungsmaßnahmen definiert. Wartbarkeit wurde als die Minimierung des Aufwandes für die Durchführung dieser Aktivität festgelegt.
Es wird behauptet, dass die Eigenschaften objektorientierter Software eher dazu beitragen, den Wartungsaufwand zu verringern, als die Eigenschaften prozedural entwickelter Software. Die Forscher haben dazu fünf Hypothesen aufgestellt:
Um zu klären, ob diese Annahmen wirklich zutreffen, hat Professor Eierman 162 fortgeschrittene Studenten in sein Experiment eingebunden. Die Studenten hatten sowohl COBOL als auch Smalltalk gelernt. Sie wurden aufgefordert, entweder eine COBOL- oder eine Java-Anwendung zu korrigieren und zu verändern. Sie sollten zum einen einen Fehler ausbessern und zum anderen eine zusätzliche Kalkulation in den Code einbauen. 81 Studenten haben Smalltalk gewählt und 81 COBOL. Daraus ergaben sich die in Tabelle 1 zusammengefassten Ergebnisse.
Das Team von Professor Eiermann schloss daraus, dass es keinen signifikanten Unterschied zwischen der Wartbarkeit der prozeduralen und der objektorientierten Lösungen gab. Was durch die eine Tätigkeit gewonnen wird, geht durch die andere verloren. Am Ende hat die Wartung der Smalltalk-Lösung sogar 3 Prozent mehr gekostet. Eierman und Dishaw kommen zu dem Schluss, dass OO-Software nicht leichter zu pflegen ist, zumindest nicht nach den Ergebnissen ihrer Studie.
Einen Vergleich der Wartbarkeit von COBOL- und Java-Code hat der Autor dieses Beitrags selbst an der Fachhochschule Hagenberg durchgeführt. Dort erhielten Studenten die gleiche Aufgabe – eine Auftragsbearbeitung in COBOL sowie in Java – und wurden aufgefordert, in beiden Versionen einen Fehler zu korrigieren und eine Änderung durchzuführen.
Die Fehlerkorrektur war in dem COBOLCode in allen Teams am schnellsten erledigt – kein Team brauchte mehr als eine Stunde. Die Änderung ging in dem JavaCode hingegen schneller. Es war leichter, eine zusätzliche Unterklasse in Java anzulegen, als einen neuen Abschnitt im COBOL-Code umzuschreiben. Kein Team brauchte für die Java-Erweiterung mehr als zwei Stunden. Für die COBOL-Änderung brauchten sie deutlich länger.
Das mag daran liegen, dass die Studenten mit Java besser vertraut waren. Es zeigt aber auch, wie schwierig es ist, solche Vergleiche zu machen. Die Subjekte solcher Studien werden immer mit der einen Technologie besser vertraut sein als mit den anderen. Wartbarkeit ist schwer zu messen, weil Wartung viele unterschiedliche Tätigkeiten beinhaltet – Fehlerkorrektur, Änderung, Erweiterung, Optimierung und Sanierung. Was in der einen Programmiersprache leicht geht, geht in der anderen schwer. Am Ende können wir nur resümieren, dass Aussagen über Wartbarkeit nicht verifizierbar sind. Es mag sein, dass die Objektorientierung langfristig zu einer Reduzierung der Wartungskosten führt, es ist aber sehr schwer, dies zu beweisen.
Ein Großteil der Wartungskosten ist auf den Test zurückzuführen, und der zusätzliche Aufwand für den Test objektorientierter Systeme ist unumstritten. Robert Binder, international anerkannter Testexperte und Autor mehrerer Bücher über Tests, behauptet, OO-Software ist nicht nur schwieriger zu testen, sie verursacht auch mehr Fehler. Boris Beitzer meint, es kostet viermal mehr, OO-Software zu testen als bisherige prozedurale Software, und James Martin, der Guru der strukturierten Welt, sah mit der Einführung der Objekttechnologie eine riesige Welle an Testaufwand auf uns zurollen.
Erstens führt die starke Modularisierung zu mehr intermodularen Abhängigkeiten. Methoden in einer Klasse unter Test verwenden Methoden in anderen Klassen, und diese benutzen wiederum weitere Methoden in noch weiter entfernten Klassen. Einer der Autoren dieses Beitrags hat verzweifelt versucht, alle externe Referenzen von C++-Klassen zu simulieren, um sie testen zu können. Zum Schluss musste er aufgeben, weil es keine Möglichkeit gab, so viele Stubs zu kodieren. Dasselbe Problem stellt sich auch bei JUnit. Um die eine Klasse zu testen, muss der Tester alle anderen betroffenen Klassen in dem Test einbeziehen oder er muss sie durch „class flattening“ simulieren. So oder so hat der Tester mehr Aufwand, als wenn das Testobjekt allein für sich getestet werden kann.
Zweitens erhalten datenbezogene Klassen Methoden, die zwar prozedural voneinander unabhängig sind, jedoch über gemeinsame Datenattribute miteinander verquickt sind. So kann die eine Methode einen Objektzustand hinterlassen, der das Verhalten der Nachfolgemethoden beeinflusst. Zum Eingabebereich einer Methode gehören nicht nur die Parameter, die von außen kommen, sondern auch die internen Attribute des gekapselten Objektes. Ihr Zustand beeinflusst den Test und muss vom Tester vorbestimmt werden. Es kommt darauf an, nicht nur alle Zweige in allen Methoden, sondern auch alle relevanten Objektzustände zu testen. Drittens ist bei der Entwicklung einer vielfach verwendbaren Klasse noch nicht bekannt, zu welchem Zweck die Methode verwendet wird. Sie musste so konzipiert werden, dass sie jeden potenziellen Zweck erfüllen kann. Derartige Offenheit zwingt zu einem umfangreichen Test, der alle möglichen Verwendungsmöglichkeiten abdeckt. Wiederverwendung hat ihren Preis.
Bereits 1996 hat Capers Jones 600 objektorientierte Projekte in 150 unterschiedlichen Anwendungsbetrieben untersucht und ist zu den folgenden Schlüssen gekommen:
Es war zu erwarten, dass die Objekttechnologie den Testaufwand in die Höhe treibt. Der objektorientierte Code hat viel mehr Abhängigkeiten und viel mehr Verwendungsmöglichkeiten. Um sie alle zu testen, muss ein größerer Aufwand betrieben werden. Die Antwort folgte in Form der Testautomatisierung. Um das Testproblem in den Griff zu bekommen, blieb den Anwendern nichts anderes übrig, als den Test zu automatisieren. Das lässt sich auch positiv auslegen. Der hohe Aufwand, objektorientierte Software zu testen, hat die Testautomation unumgänglich gemacht.
In der Sache Wiederverwendung bestehender Software hat die Objekttechnologie unbestreitbare Vorteile. Sie ermöglichte den Aufbau allgemeingültiger Klassenbibliotheken, die von Projekt zu Projekt weitergereicht werden können. Es gibt mehrere Berichte über Projekte, in denen mehr als 50 Prozent des geschätzten Aufwandes durch die Wiederverwendung von Code aus früheren Projekten eingespart wurde. Allerdings ist es fraglich, ob die gleiche Ersparnis nicht auch mit prozeduraler Software möglich gewesen wäre. Lange vor der Einführung der Objekttechnologie haben Capers Jones in den U.S.A. und Albert Endres in Deutschland über Erfolge bei der Wiederverwendung von Codebausteinen berichtet. Allgemein verwendbare Subroutinen, Makros und Include- beziehungsweise Copy-Codestrecken wurden schon in den Siebzigerjahren verwendet, um Code einzusparen. Endres beschreibt auch andere Wiederverwendungstechniken, die über den Code hinausgehen – Techniken wie Entwurfsmuster, Application-Frameworks und Standardschnittstellen. Es wäre daher nicht korrekt zu behaupten, Wiederverwendung sei eine Errungenschaft der Objektorientierung. Es gibt auch Prozess- und Funktionswiederverwendung. Allein die Vererbung fördert direkt die Wiederverwendung übergeordneter Klassen- und sie ist unter Experten umstritten.
Was die Wiederverwendung betrifft, hat die Objektorientierung nur bedingt dazu beigetragen, diese zu erhöhen. Das Konzept der abstrakten Datentypen hat sicherlich mehr dazu beitragen. Ob wir das mit der Objektorientierung gleichsetzen wollen, bleibt dahingestellt. Zum Schluss können wir feststellen, dass Objektorientierung die Wiederverwendung vorantreibt, aber keine unabdingbare Voraussetzung für sie ist. Product Line Management belegt, dass auch nicht-objektorientierte Software durchaus wiederverwendbar ist.
Niemand würde bestreiten, dass Objektorientierung zu einer besseren Portabilität geführt hat, zumindest was Java betrifft. Die gekapselten Objekte mit ihren standardisierten Schrittstellen lassen sich von einer Umgebung zur anderen ohne Weiteres versetzen. Leider ist es nicht möglich, Komponenten zu versetzen, ohne sie neu zu kompilieren, aber dafür lässt sich der Bytecode übertragen. Jedenfalls ist die Portabilität viel stärker als bei den klassischen prozeduralen Sprachen, bei denen man die Module neu kompilieren und binden muss. Die Versetzbarkeit von Software ist heute eine Grundvoraussetzung für die Übertragung lokaler Anwendungen auf die Cloud. Die strenge Aufteilung des Codes in Klassen, Methoden und Schnittstellen macht es möglich, lokale Klassen als globale Webservices wiederzuverwenden. Dies ist bei den prozeduralen Sprachen wie COBOL, C und PL/I nicht ohne Weiteres möglich. Einer der Autoren hat sich jahrelang damit beschäftigt, solche prozeduralen Programme zwecks der Wiederverwendung als Services zu kapseln. Das erfordert die Erstellung ganz neuer Schnittstellen. Mit objektorientiertem Code geht das viel einfacher.
Es gibt aber auch kritische Stimmen zur Objektorientierung. Victor Basili, Professor für Informatik an der Universität Maryland, gibt zu bedenken, ob
„Object-oriented is the right way to think in all domains. It is obviously good for some, but we still don’t have enough empirical evidence to support the claim that it is good for all …”
Erik Stenstrud, Professor an der Norwegian School of Management, führte ein Experiment durch, um die Produktivität in objektorientierten Projekten mit der in prozedural orientierten Projekten zu vergleichen. Das Ergebnis war nicht eindeutig. Am Ende war die Produktivität in etwa gleich. Die Nachteile der Objektorientierung haben die Vorteile ausgeglichen.
Professor Thomas Niemann vom Portland Community College behauptet, eine übertriebene Nutzung aller Eigenschaften der Objekttechnologie kann produktivitätshemmend wirken. Er meint: „excessive information hiding can be detrimental“ und dass Vererbung und Polymorphismus den Test erschweren. Wenn zu viel Information verborgen bleibt, kann ein Fremder den Code nicht korrigieren. Letztendlich kommt Niemann zu dem Schluss, dass die Produktivität an ehesten durch eine OOLite zu erreichen ist.
Eine kritische Stimme in Sachen Objekttechnologie kommt von Professor Manfred Broy. So schreibt er in einem Beitrag für das Informatik-Spektrum zusammen mit Johannes Siedersleben:
_„Wir vertreten die These, dass die heute gebräuchliche Objektorientierung zwar eine ganze Reihe interessanter, vorteilhafter Eigenschaften besitzt, dass es aber auch einige gravierende Mängel gibt, die zeigen, dass die Objektorientierung nicht auf dem aktuellen Stand der wissenschaftlich verstandenen Programmiermethodik und des Software Engineering ist.“.
Weiterhin behaupten die Autoren: „Objektorientierung löst trotz ihrer Beliebtheit und Verbreitung längst nicht alle alten Probleme und manche Neue hat sie erst geschaffen.“ Besondere Bauchschmerzen verursacht die Vererbung und die Verwendung von Objektreferenzen bei der Polymorphie, die nichts anderes sind als notdürftig verhüllte Pointers. Dazu kommt in der Entwurfssprache UML
Das, was Broy und Siedersleben am meisten kritisieren, sind weniger die OO-Konzepte an sich, als die Umsetzung dieser Konzepte in konkrete Sprachen wie C++, Java und insbesondere UML.
Das fehlende Komponentenkonzept erschwert den Entwurf einer komplexen Architektur. Die Klassen sind viel zu klein, um als höchstes Abstraktionselement zu dienen. Die Autoren stellen fest:
„Einer der schlimmsten Mängel der Objektorientierung ist die Abwesenheit von Komponenten als Ergänzung zur Klasse. Klassen sind einfach zu klein, zu feingranular. Sie sind Einheiten der Implementierung, nicht der Konstruktion. Große Systeme lassen sich damit kaum strukturieren“.
Broy und Siedersleben erwähnen keine empirischen Studien, um ihre Kritik der Objekttechnologie zu untermauern, aber aus ihrem Wortlaut ist zu entnehmen, dass die Objektorientierung keine Veränderung der Produktivität verursacht. Die positiven, produktivitätssteigernden Einflüsse werden durch die negativen produktivitätshemmenden Eigenschaften ausgewogen. Am Ende bleibt es bei plus/minus Null.
Eine der interessantesten Studien zum Thema Objekttechnologie und Produktivität wurde 1994 in den Communications of the ACM unter dem Titel „Requirements Specification – Learning Object, Process and Data Methodologies“ veröffentlicht. Die Autoren sind Iris Vessey und Sally Conger. Beide Autoren – eine Professorin und ein Berater – haben eine Untersuchung durchgeführt, wie gut Durchschnittsentwickler mit der Objektorientierung zurechtkommen. Entspricht sie wirklich der natürlichen Denkweise? Im Vergleich zu anderen Entwicklungsmethoden war für die beteiligten Menschen die OO-Methode am schwierigsten zu erlernen. Also entspricht dieser Ansatz keineswegs der natürlichen Denkweise.
Aus der Produktivitätsdiskussion ist zu schließen, dass Objektorientierung nicht zwangsläufig zu einer höheren Produktivität führt. Es kommt darauf an, wer an dem Projekt beteilig ist und wie hoch der Wiederverwendungsgrad ist. Wenn erfahrene Entwickler mit fundierten Kenntnissen der verwendeten Sprachen, zum Beispiel UML und Java, am Werk sind und wenn über 50 Prozent des Codes wiederverwendet wird, ist eine signifikante Produktivitätssteigerung im Vergleich zur prozeduralen Entwicklung zu erwarten.
Wenn aber die Projektbeteiligten wenig OO-Erfahrung besitzen und die Wiederverwendungsrate niedrig ist, dann ist eher mit einem Produktivitätsverlust zu rechnen. Unerfahrene Entwickler und eine hohe Wiederverwendungsrate deuten auf eine gleichbleibende Produktivität. Erfahrene Entwickler und eine niedrige Wiederverwendungsrate deuten auf eine geringe Steigerung der Produktivität hin – 1 bis 50 Prozent. Somit ist die Frage nach dem Einfluss der Objekttechnologie nicht eindeutig zu beantworten.
Wenn wir uns am Ende fragen, was die objektorientierte Bewegung für die Softwarewelt gebracht hat, müssen wir einiges von den ursprünglichen Behauptungen abziehen.
In dem einen oder anderen Fall ist der Aufwand für die Softwareentwicklung gesunken, vor allem dort, wo eine hohe Wiederverwendungsrate erzielt und wo erfahrene OO-Entwickler am Werk waren. Wo wenig wiederverwendet und wo unerfahrenes Personal eingesetzt wurde, sank die Produktivität. Die richtige Anwendung der Objektorientierung stellt hohe Anforderungen an Entwickler. Wenn sie dem nicht gewachsen sind, ist ihre Produktivität begrenzt.
Im Vergleich zu manchen Sprachen der 4. Generation schneiden Java und C++ schlecht ab. Nur C# im Zusammenhang mit .Net kann einigermaßen mithalten. Bei der Untersuchung der Produktivität in einem großen österreichischen Industrieunternehmen hat einer der Autoren festgestellt, dass
Also ist die Steigerung der Produktivität nicht gerade eine Stärke der Objekttechnologie, vor allem nicht, wenn Unerfahrene am Werk sind.
Es gibt keine empirisch untermauerten Beweise dafür. Die wenigen Untersuchungen, die es gibt, deuten auf ein plus/minus Null in der Wartung hin. In einigen Fällen ist die Wartbarkeit der Software gestiegen, vor allem in Fällen, wo die Codemenge signifikant reduziert und wo viele Standardbausteine eingesetzt wurden.
In anderen Fällen ist die Komplexität der Software so gestiegen, dass das Wartungspersonal damit nicht mehr zurechtgekommen ist. Die Wartungskosten sind gestiegen. Ohne regelmäßige Refakturierung gerade komplexer OO-Systeme gerieten diese außer Kontrolle. Bei prozeduralen Systemen konnten die Entwickler sie mehr schlecht als recht am Leben halten. Dies ist bei der Objektorientierung nicht der Fall.
Die Antwort auf diese Frage ist bedingt ja. Objektorientierte Komponenten sind in der Regel von ihrer Umgebung leichter loszulösen und einfacher zu kapseln. Dieser Schluss lässt sich aus der Erfahrung von einem der Autoren mit Wiederverwendung von Klassen als Webservices ableiten. Anderseits gibt es zu wenige echte wissenschaftliche Beweise für diese Behauptung. Software wurde im hohen Maße schon vor der Objektorientierung wiederverwendet. Es ist schwer zu sagen, wie weit die Objektorientierung die Wiederverwendung erleichtert hat. Man kann allenfalls behaupten: Es spricht vieles dafür.
Diese Behauptung trifft am ehesten von allen zu. Dadurch, dass der Code genormte Schnittstellen hat, kann man ihn in fremde Umgebungen versetzen und mit geringem Anpassungsaufwand zum Laufen bringen. Entwickler müssen den Code nicht umschreiben. Dies ist in der heutigen Welt der verteilten Verarbeitung ein entscheidender Vorteil. Das Konzept der verteilten Objekte passt gut zu der heutigen vielfältigen digitalen Welt. Mit der Portabilität hat die Objekttechnologie wichtigen Weichen gestellt.
Zusammenfassend kann man sagen, dass die Objektorientierung längst nicht alles erreicht hat, was sie ursprünglich versprochen hat – vor allem was Produktivität und Wartungserleichterung betrifft. Dafür hat sie andere positive Effekte auf die Softwareentwicklung gehabt. Sie fördert die Wiederverwendung und befreit die Software von der Abhängigkeit zu einer proprietären Umgebung. Objektorientierung hat die Welt der Software geöffnet- allein dadurch hat sie sich gerechtfertigt.