Wiederverwertbarkeit von Objekten gab es nie wirklich.

[Smacks]

Unten steht ein Ausschnitt aus einem Artikel von 2001. In dem Artikel geht es darum, dass sich der CIO weiterentwickeln muss zu einem CPO, einem Chief Process Officer, d.h. hier: er soll die IT-Infrastruktur in Zukunft so anpassen, dass die Unternehmens-IT leicht unterschiedlichste Geschäftsprozesse integrieren kann usw. usf.

Dabei sollte der CIO von heute auch drei Mythen über Bord werfen. Eine davon wird im Artikel Plug-and-Play-Reusability genannt. Die Autoren meinen unter anderem, dass es niemals in der Geschäftswelt je ein Problem gab, dass mithilfe von zwei Objekten gelöst wurde, die nicht speziell dafür programmiert wurden. Stimmt das wirklich? Was dann zu EJB und COM geschrieben wird, kann ich nicht beurteilen. Das VB aber auch heute eine der wichtigsten Programmiersprachen in der Geschäftswelt ist, würde ich fast unterschreiben.

Schreibt mal bitte, was ihr so davon haltet, auch wenn's etwas philosophisch vielleicht wird...

Second, in terms of reusability, OOAD
has been disappointing. OO is entrenched
in the IS development life cycle, but this
is far more the result of good salesman-
ship than of demonstrated effectiveness.
If objective productivity improvement
measures for OO techniques exist, they’re
neutral at best and generally negative.

There’s never been an instance in the
commercial world of two “objects”
being plugged together to create a solu-
tion to a problem for which they were
not specifically designed. In general,
objects are hostile to each other within a
given class hierarchy, immensely hostile
to each other across class hierarchies,
and impossibly hostile to each other
across languages. The closest thing we
have to plug-and-play is the Component
Object Model (COM) and Enterprise
JavaBeans (EJB) component architec-
tures, more accurately described as
“plug-and-program,” and more com-
monly described as “plug-and-pray.”
EJB is an extension of Java and, there-
fore, grounded in OO, but it’s certainly
not plug-and-play. COM is language-
neutral, but its component model hails
from early versions of Visual Basic
(VB), which was emphatically not OO.

Interestingly, VB was and continues
to be derided by the OO community in
spite of the fact that it single-handedly
created the reality of commercial,
reusable software components — some-
thing that OO promised but never deliv-
ered. VB went on to become the num-
ber-two language for business applica-
tions that are actually sustained in pro-
duction. In this category, VB lags only
COBOL, another widely used language
derided by the OO community.

Finally, the term “software stan-
dards” is another oxymoron because
there are so many to choose from. The
reality today is that large-scale enter-
prise IT is a Tower of Babel with each
application communicating in its own
unique language. Fortunately, we have
TCP/IP, which is a universal standard at
the physical network communications
level. eXtensible Markup Language
(XML) is quickly becoming the de facto
standard “alphabet.”

But just because English and French
are based on largely the same alphabet
doesn’t mean that the two can commu-
nicate. In the IT world, there’s no quick
solution for the semantics problem. Just
as natural languages can’t be “engi-
neered,” a common IT language must be
allowed to evolve over several years.

 

[foobar]

Das VB aber auch heute eine der wichtigsten Programmiersprachen in der Geschäftswelt ist, würde ich fast unterschreiben.

Ich nicht.

 

[AlArenal]

MIr liegen keine Zahlen zur Verbreitung diverser Sprachen vor, die belegen oder widerlegen, was dort über VB gesagt wird. Größtes Problem dürfte dabei die Erfassung von Software sein, die rein für den firmeninternen Gebrauch konzipiert wird. Gerade in diesen Umfeldern dürfte es einen Wust an Anwendungen geben, die mit Access oder Excel erstellt wurden; k.A. ob VB hier synonym für VBA steht.

Was über das gebrochene Versprechen der OO in Bezug auf Widerverwendbarkeit gesagt wurde, mag in dem gesetzten Kontext sogar gar nichtmal sooo verkehrt sein. Allerdings werden zwei Systeme heutzutage auch nicht miteinander verbdunden, indem man Sourcecode zusammen manscht. Wenn du eine Anwendung an ein CRM anbindest, dann machst du das über verfügbare Schnittstellen. Das können auch bereitsgestellte Libs sein (dann wäre das o.g. falsch), das sind oft genug aber irgendwie geartete Import-/Export-Mechanismen oder halt die allgegenwärtigen Webservices.

Ganz fair ist diese Sichtweise aber m.E. nicht. Wenn Autohersteller XY und YZ in einer gemeinsamen PLattform gewisse bauteile verwenden, die dann allen gemein sind, müssen diese noch nicht in allen anderen Plattformen und Modellen einbaubar sein. Dennoch sind sie in einem definierten Bereich, für dessen EInsatz sie entwickelt wurden, wiederverwendbar und sparen dadurch Kosten für Neuentwicklung, etc. Praktisch erlebte Wiederverwendbarkeit ist doch jede Lib und jedes Framework, dass wir wiederkehrend in unsere Anwendungen einbauen. Das können Entwicklungen Dritter sein, ebenso wie Eigenentwicklungen, die nunmal wiederkehrend in eigenen Projekten und Produkten benötigte Komponenten kapseln. Das ich meine Java-Libs nicht einfach an den PHP-Frickler von nebenan weitergeben kann und der benutzt die dann, liegt in der Natur der Dinge (Ja, ich weiß, dass man in PHP auch Java-Klassen verwenden kann.. ) und verhält sich analog zuu o.g. Auto-Beispiel. Nur wäre es unfair zu behaupten, die OO habe ihr Versprechen von der Wiederverwendbarkeit nicht eingehalten, denn dieses wurde nie derart ausgedrückt, dass eien Wiederverwendbarkeit beliebig über die Grenzen einer Sprache erreichbar wäre.

Wenn ich Aussagen nur genug verdrehe, ist es natürlich einfach sie zu widerlegen. Das sagt mehr über den Autoren aus, als über das, worüber er schrieb. In diesem Fall scheint er ein "VB-Möger" zu sein. Dass man hie rund da über die Unüberschaubarkeit der Vielzahl von Lösungen stolpert, ist in der Tat ein Problem. Da OO aber für mich ein Konzept aus der Natur ist und ich Software gerne als Lebewesen betrachte, halte ich es auch für eine Tatsache, dass die natürliche Selektion auch in der Software-Entwicklung gemäß Darwins "survival of the fittest" über kurz oder lang dafür sorgen wird, dass sich Lösungen durchsetzen und andere (in Nischen oder ganz) verschwinden werden.

Hat die Speisekarte nur 10 Einträge, ist es natürlich einfacher sich zu entscheiden. Das alleine sagt nur noch nciths über die Qualität des Essens aus.

 

[SnooP]

Naja... - also VB als eine wichtige Programmiersprache - ich weiß ja nich ... ABAP ja - leider... aber VB? Ist der Artikel eigentlich schon älter? Denn COM ist ja nu mehr oder weniger von .Net abgelöst worden und bietet deutlich mehr an objektorientierter Funktionalität...
und letztlich... Wiederverwendbarkeit von Softwarekomponenten ist tatsächlich immer so ne Sache, allerdings gibt es doch immer wieder zentrale Komponenten die Aufgaben erledigen, die in allen Bereichen gefordert werden. Und wenn man tatsächlich in anderen Projekten wieder alles neu programmieren muss, so gibts zumindest innerhalb eines Projekts die Wiederverwendbarkeit dank oop - zumindest ist das bei mir so

 

[SnooP]

Praktisch erlebte Wiederverwendbarkeit ist doch jede Lib und jedes Framework, dass wir wiederkehrend in unsere Anwendungen einbauen. Das können Entwicklungen Dritter sein, ebenso wie Eigenentwicklungen, die nunmal wiederkehrend in eigenen Projekten und Produkten benötigte Komponenten kapseln.

Exakt - seh ich genauso!

 

[Smacks]

Also erst mal Danke für die Antworten!

Der Artikel ist schon älter, von 2001 und wurde von zwei CSC-Beratern geschrieben, die sich mit EAI-Zeugs beschäftigen... Inwieweit jetzt CSC MS-Produkte vertreibt, weiß ich nicht.

Also ich unterstelle jetzt mal, dass die Autoren nicht nur um der Provokation Willen Stuss zusammengeschrieben haben (Auch wenn sich der Verdacht ein wenig aufdrängt :wink: ). Vielleicht hab ich's ein bisschen aus dem Kontext gerissen, also die "drei Mythen", die ein CIO über Bord werfen sollte, sind:

(1) Plan-Based Information Engineering

(2) Inconsistent Data Must Be Eliminated

(3) Plug-and-Play Reusability (Siehe Zitat im ersten Post)


(1)
Mit "Plan-Based Information Engineering" meinen die, dass man eben nicht die Unternehmens-IT in einem Guss irgend wie planen kann. "In this continually changing environment, you can't know whether a business process implementation will be "right" by the time it's implemented. So the concept of an end-state vision is meaningless". Also weg von der zentralisierten IT-Architektur.

(2)
Also das bezieht sich vor allem auf internationale Konzerne, die sagen schon, dass konsistente Daten auf Länderebene z.B. sinnvoll sind. Es sei aber unmöglich Duplikate und Inkonsistenzen zu vermeiden, wenn in den einzelnen Ländern die Programme an die lokalen Gegebenheiten angepasst werden.

Na ja, zumindest bei Oracle, wenn ich jetzt nicht irgend welchen Werbesprüchen aufgesessen bin, ist es ja anders als bei SAP möglich, auch in internationalen Konzernen dank des zentralen Datenbankmodells z.B. per Knopfdruck alle Mitarbeiter zu zählen, o.ä.. Was bei SAP schwieriger ist, da überall eigene SAP R/3 Dinger rumstehen. Hier finde ich also so ein einheitliches Datenmodell nicht schlecht.

Vielleicht haben sie aber Recht, dass der Aufwand für konsistente Daten zu hoch ist. ANdrerseits wer verlässt sich dann noch gerne auf die Daten?

(3)
Habe ich ja schon oben gepostet. Also vielleicht meinen die nur, dass man nicht versuchen sollte, eine zentralistische Unternehmens-IT anhand von OO aufzubauen. Wenn die Autoren gleichzeitig EAI favorisieren, dann wollen Sie vielleicht auf sowas hinaus:

Was über das gebrochene Versprechen der OO in Bezug auf Widerverwendbarkeit gesagt wurde, mag in dem gesetzten Kontext sogar gar nichtmal sooo verkehrt sein. Allerdings werden zwei Systeme heutzutage auch nicht miteinander verbdunden, indem man Sourcecode zusammen manscht. Wenn du eine Anwendung an ein CRM anbindest, dann machst du das über verfügbare Schnittstellen. Das können auch bereitsgestellte Libs sein (dann wäre das o.g. falsch), das sind oft genug aber irgendwie geartete Import-/Export-Mechanismen oder halt die allgegenwärtigen Webservices.

oder?


Ich freue mich über weitere Antworten, einige Sachen sind mir jetzt schon klarer geworden. Obwohl ich mir wirklich unsicher bin, ob ein CIO diese drei "Mythen" wirklich aufgeben muss, um in einem Unternehmen EAI zu integrieren, bzw. zum CPO zu werden...

 

[AlArenal]

SAP ist eh so ein Fall für sich.. Je nachdem was du für Module und Anpassungen hast, müssen Daten mehrfach gepflegt werden. Aus dem Bereich der Personalstammdaten ist mir das z.B. bekannt. Du hast die einmal eh schon vorgesehen, dann hast du sie nochmal extra für HR und wenn du ein eigenes Modul brauchst, denk mal nicht, dass die auf vorhandenen Daten aufbauen würden...

Ich bekomme das derzeit aber (noch) nur am Rande mit. Unternhemensberater, vor allem die großen, sind eh so zwielichtige Gestalten.. Ich hab mich mal nen Samstag Nachmittag mit einem zusammengesetzt, der mich mal in die wundersame Welt von SAP einführen wollte. Als wenn einer ein Fremdwörterlexikon in einer unbekannten Sprache runterbeten würde....

 

[Caffè Latte]

Hi,

ich hatte mal von 1-2 Jahren gelesen, dass über 90% der Informatikstudenten nach dem Abschluss ihres Studiums immer noch nicht richtig wussten, wozu OOP eigentlich gut ist. Wenn dies stimmt ist auch klar, dass ein grosser Teil der Software, die mit einer objektorientierten Sprache programmiert wurde, nicht wiederverwendbar ist.

Bei meinem Arbeitgeber nutzen wir seit über fünf Jahren eine (ständig wachsende) Klassenbibliothek für eine Vielzahl von Anwendungen. Ist zwar alles C++, aber das ist ja im Grunde wurscht. Und für mein privates Java-Projekt nutze ich meine stetig wachsende Klassenbibliothek mit z.Z. ca. 15 Klassen. Allerdings werde ich diese Klassenbibliothek in anderen privaten Projekten nicht nutzen können, da ich das Projektende wohl nicht mehr erleben werden ...

Just my 2 cents ...

 

[AlArenal]

Auch unter Informatik-Studenten gibt es eine digitale Kluft. Ich kenne einige, die zumindest in Bezug auf Programmierung keinen PLan von irgendwas haben, geswchweige denn von Software-Engineering und Projekt-Management. Das äußert sich dann auch zum Teil in lächerlichen Gehältern und Jobs als Diplom-PHP-Mädchen-für-alles.

 

[SnooP]

Naja... in vielen Fällen musst du ja als Informatiker ja nu auch nicht das Programmier-Ass schlechthin sein... nur OOP bzw. OOA/OOD ist ja nu mal ne Abstraktionsebene höher und damit eigentlich für Informatiker genau das Richtige

 

[0xdeadbeef]

Man muß sich trotzdem darüber im Klaren sein, daß Objektorientierung zwar für viele Fälle nützlich ist, aber auch nicht der Weisheit letzter Schluß. Es gibt Sachen, sie kann man zwar in ein Objekt packen, aber irgendwie bringt einen das auch nicht weiter.
Beispiele wären die u.U. nutzlose Hauptklasse einer Java-Anwendung und statische "Sammelklassen" wie Math. Objektorientierung bringt natürlich eigentlich wirklich nur dort, wo man erben kann - beispielsweise in der Oberflächenprogrammierung. Kapselung ist natürloch auch ein Thema, aber da ist der Vorteil gegenüber strukturierten Sprachen nicht ganz so deutlich.
Last but not least macht eine Klassenhierachie, die auf optimale Wiederverwertung ausgelegt ist, ein Projekt unter Umständen recht unübersichtlich. Wenn man pro Objekt immer nur eine neue Methode oder Variable einführt und der Rest wird geerbt, fällt es schwer, sich einen Überblick zu verschaffen, welche Methoden und Variablen ein Objekt denn nun eigentlich hat. Auch die Funktion des Konstruktors wird schwer nachvollziehbar, wenn man 5 oder 5 super()-Aufrufe verfolgen muß.

 

[Grizzly]

Ich sehe das mit der OOP eher ganz pragmatisch. Habe Jahre lang - damals noch unter DOS - prozedural programmiert. Und vor allem, wenn man anfängt, mit Fenster, Button, usw. zu arbeiten (damals noch selbst entwickelt ), stößt man ziemlich schnell an Grenzen. Da musst Du dann jeder Prozedur (bzw. Funktion) jedesmal 150 Parameter mitgeben. Ist sehr unübersichtlich und auch nur sehr schlecht zu warten. Okay, okay, man kann sich dann mit Structs behelfen (in Pascal hies das Record - glaube ich ), aber das ist irgendwie auch nicht so der Renner. Bei der OOP kann ich Variablen (die dann netterweise Eigenschaften heissen) und Funktionen (die dann Methoden genannt werden) das ganze etwas besser bündeln und viel übersichtlicher gestalten. Zur Geschichte der Vererbung & Co. bin ich selber erst im zweiten Schritt gekommen.
Im Geschäft werden bei uns viele Klassen wiederverwendet, da wir mehr oder weniger auf einer großen Java Anwendung aufbauen. Kleiner Programme, die nebenher entwickelt werden, profitieren aber auch davon.

Zum Thema zentralisierte IT und Redundanz kann ich aus meiner Praxis nur sagen: Meist hat man eh mehrere Systeme, die je ein Gebiet abdecken (außer man hat vielleicht ein ERP am Laufen). Und da kommt die Redundanz von Daten ganz automatisch.

Hoffe, ich habe jetzt nicht ganz am Thema des Threads vorbeigeschrieben.

 

[0xdeadbeef]

Also die Übergabeparameter sind nun wirklich kein Argument für OOP. Setter- und Getterinterfaces kann man genauso in einer strukturierten Sprache schreiben. Statt einem automatischen Konstruktor ruft man halt nach jeder Allokierung eine Init-Funktion.

 

[Grizzly]

Also die Übergabeparameter sind nun wirklich kein Argument für OOP. Setter- und Getterinterfaces kann man genauso in einer strukturierten Sprache schreiben. Statt einem automatischen Konstruktor ruft man halt nach jeder Allokierung eine Init-Funktion.

In C könnte ich vielleicht mit Pointer auf Funktionen die Sache lösen. In Pascal oder Basic wüsste ich jetzt aber keine Umsetzung. Mal davon abgesehen, dass das nicht sehr benutzerfreundlich ist. :?
Gut, dass mit der Init Funktion wäre noch zu verkraften.