Larry Constantine redet einer pragrnatischen Auffassung das Wort

Objekt- und funktionsorientiertist kein unlösbarer Widerspruch

29.03.1991

WIEN (qua) - Funktionsorientierte und objektorientierte Software-Architekturen schließen sich nicht aus; möglicherweise lassen sich beide Entwurfsmethoden sogar miteinander mischen. Diese These vertrat Software-Guru Larry Constantine auf einem Seminar, das die GMO AG gemeinsam mit der Digital Consulting Inc., Andover/Massachusetts, in Wien veranstaltete.

Mit einer solchen Auffassung fühlt sich Constantine derzeit noch als Ketzer wider die reine Lehre der Objektorientierung (OO): "Manche Leute sähen dafür gern meinen Kopf rollen." Seiner Ansicht nach wird die OO-Thematik vielfach zu verbissen betrachtet - "nach dem Motto: Eiffel gegen den Rest der Welt".

"Für mich ist Objektorientierung keine Frage der Religion", verteidigt sich der selbständige Berater, dessen Schreibtisch in Acton im US-Staat Massachusetts steht. Insofern seien objektorientierte Systeme mit ereignisorientierten Modulen keineswegs ein Ding der Unmöglichkeit - genausowenig wie funktionsorientierte Systeme mit entitätsorientierten Modulen.

Die - reine - funktionsorientierte Architektur beschreibt Constantine wie folgt: Sie setzt sich aus funktional-prozeduralen Modulen zusammen wird durch Funktions-/Prozedur-Aufrufe verbunden, basiert auf der funktionalen Dekomposition und ist hierarchisch gegliedert.

Eine objektorientierte Architektur besteht dementsprechend aus Objektmodulen; Operationen und Vererbungen stellen die Verbindungen her; Grundlage ist die Datenabstraktion; Peer-to-peer- oder Client-Server-Beziehungen bilden die Organisationsschemata.

Laut Constantine ist es durch aus denkbar, Systeme teilweise funktionsorientiert und teilweise objektorientiert zu gestalten. Möglich seien Hybridformen wie beispielsweise eine nichthierarchische funktionsorientierte oder auch eine durchgängig "Funktion-Objekt-orientierte Architektur" (siehe Abbildung). Eine solche gemischte Architektur könnte die jeweiligen Vorteile der Strukturmodelle berücksichtigen. Beispielsweise ist da, wo häufig Funktionen geändert werden müssen, ein funktionsorientierter Entwurf günstiger; Datenentitäten hingegen lassen sich leichter in objektorientierten Entwürfen ändern.

So undogmatisch wie die Frage der Architektur geht der Software-Experte auch die Beurteilung der Programmiersprachen an: Die besten Zukunftsaussichten bescheinigt er den Sprachen, die sowohl die traditionelle Programmierung als auch den objektorientierten Entwurf unterstützen, also den Erweiterungen konventioneller Sprachen. Dazu zählt neben C+ + und Objekt Pascal auch das objektorientierte Cobol, dessen Spezifikationen das US-Normierungsgremium Codasyl vertreibt.

Konsequenterweise sieht Constantine auch keinen Widerspruch zwischen dem relationalen und dem objektorientierten Datenbank-Modell: "Es gibt keinen Grund, warum ein System nicht beides unterstützen sollte."