Entgegen
tendenziösen Phrasen wie "...
Rückfall
von der OO- in die strukturierte
Programmierung ..."
bleiben wir auch den Tugenden, die sich in der klassischen,
prozeduralen, nicht-objektorientierten Programmierung bewährt
haben, aus guten Gründen treu. "Objektorientiert" darf z.B.
nicht
dazu führen, mit graphischen Entwicklungsumgebungen
Billigkräfte Anwendungen oder GUIs zusammenklicken zu lassen,
die
noch unstrukturierter und damit noch unwartbarer und instabiler sind
als die berüchtigten per Copy&Paste erstellten.
Nicht die strukturierte,
sondern die prozedurale
Programmierung und Denkweise wurden von der objektorientierten
abgelöst; die Begriffe "strukturierte Analyse / Design" wurden
doch nicht gegen OO, sondern gegen unstrukturierten Wildwuchs
großer Systeme ins Feld geführt.
Gute objektorientierte
Analyse, Design und Programmierung ist
immer auch gut strukturiert.
Semantische simple
Datentypen
- Classic:
Wer in der
Software-Entwicklung auf Stil hält, deklarierte schon immer
seine Datentypen,
auch die simplen
Datentypen, mit semantisch
aussagekräftigen,
vertrauenswürdigen Typ-Namen
und möglichst engen, vertrauenswürdigen
Wertebereichen, z.B.
boolean, Aufzählungs- oder Bereichs-Typen statt grob Integer
oder
long.
- Class:
Mit Einzug
des OO-Paradigmas
und der
Programmiersprache Java
anfangs der 90er-Jahre traten an die Stelle strukturierter
Typen dann Klassen
(class), doch benutzerdefinierte,
semantische simple
Datentypen wurden und werden in Java leider nicht unterstützt
(dummerweise stammten Javas Väter aus dem C++ und nicht aus
dem
Pascal-Umfeld). Damit ging viel Typkultur wieder verschütt.
- Class
umfaßt
also keineswegs Classic,
aber Classic-and-Class
versucht
die Stärken beider Welten zusammen
zu bringen. Ich selbst möchte OOA, OOD, OOP und Java nicht
mehr
missen.
Datenmodellierung
Entsprechendes gilt im Großen, in der
Unternehmens-Datenmodellierung:
Klassendiagramme ersetzen keineswegs die guten alten Semantischen
Datenmodelle, wie manche Java-Entwickler gern behaupten, sondern das
validierte
Semantische
Datenmodell
(bzw. Business Domain [Object] Model) muß Ausgangspunkt sein
(und
iterativ bleiben) für
- Klassendiagramme
einerseits und
- physische Datenbankschemata
(incl. semantische Constraints) andererseits.
Enterprise Application
Integration (EAI)
Auch dort, wo Systeme eines Unternehmens nicht mehr in ein
einheitliches Unternehmensdatenmodell gefaßt werden
können
und / oder Funktionalitäten heterogener Systeme
mittels
Enterprise
Application Integration (EAI)
integriert werden müssen,
- reicht OO allein nicht
aus,
- bietet andererseits
aber gerade die J2EE Connector
Architecture (JCA)
eine standardisierte Schnittstelle, die das einstige M:N-Verhältnis
zwischen Application Server Schnittstellenimplementierungen und
Enterprise Information System Schnittstellenimplementierungen reduziert
- zu einem 1:1
Verhältnis
aus AppServer-Sicht (der jede EIS seine JCA-Standard-Schnittstelle
implementieren läßt) und
- zu einem 1:1- bzw.
1:Wenige-Verhältnis aus
EIS-Anbieter-Sicht.
Dadurch wird der jeweilige Integrationsaufwand technisch wie
wirtschaftlich tragbar und zukunftssicher.
Thomas Taeger
Nachtrag
zu Java-Typen:
Seit
Java-5
nähert sich
Java mit seinen
generischen und
parametrisierten Typen/Klassen
(und damit Typsicherheit) und
sogar Aufzählungstypen (
enum-Klassen)
endlich dem Stand an, den der Volks-Compiler Turbo-Pascal schon vor
zwei Jahrzehnten bot - bravo ... . Typsicherheit ist ja nicht nur Stil,
sondern zentrale Voraussetzung für robuste Software. Und auf
benutzerdefinierte, semantische simple Datentypen, u.a. abgeleitete und
Bereichs-Typen, dürfen wir im Laufe der nächsten zwei
Jahrzehnte sicher auch noch hoffen.