Classic-and-Class

 
Classic-and-Class
statt
classic vs. class
 

Der Name ist Programm


Faustformel: 'Außen semantisch, innen generisch'

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.


Classic-and-Class