Sonstiges > Offtopic

OO - Definition für Neueinsteiger

<< < (6/7) > >>

Hernan Cortez:
Wenn dir beim Warten langweilig wird, kannst du ja in der Zwischenzeit hier ein bischen schmökern.  ;D

http://c2.com/cgi/wiki?ObjectOrientation

grossartiger Grusel to deepen your angst :o

animate:
einige kurze und nicht so tiefe Erklärungen und Erzählungen gibts auch bei uns auf der Homepage (link ist unter meinem Avatar). Dort im Menü auf Fachliches klicken und dann auf Objektorientierung. Und dann gibts da noch eine Menüebene drunter, die evtl. ein paar erste Fragen beantwortet.

Hernan Cortez:

--- Zitat von: Semeaphoros am 17.04.04 - 15:52:17 ---Mit Uebung lässt sich bei kleinen Sachen OOA und OOD durchaus auch im Kopf machen, aber gemacht werden muss es, und den Kopf kann man ganz gut mit Papier, Bleistift, Radiergummi, und wer mag Kaugummi oder Cervisia unterstützen.

--- Ende Zitat ---

Ich stimme damit nicht überein.
An eine Anwendung werden Anforderungen aus der realen Welt gestellt (business cases).
Ein OO-Analyst bildet diese business cases in einem Objektmodell ab.
Mit UML Diagrammen kann man verschiedene Sichten dieses Objektmodells darstellen.

Genau diese Sichten liefern etwas, woran es heute in vielen Unternehmens-ITs mangelt: Eine übersichtliche, menschenlesbare Dokumentation der Anwendungen.
Vielleicht sehe ich das aber auch nur stärker als Problem als andere Kinder, da ich eben oft in Notes Projekte kam, die vor die Wand gelaufen waren und die Java/J2EE Projekte im Team entwickle (so ungewöhnlich auch nicht, d.h. viele von euch werden sich da wiedererkennen). Für beide Aufgaben stellt eine vernünftige Dokumentation einen hohen Wert dar.    
Diagramme stellen Information wesentlich übersichtlicher dar als Source code dar. Tool (z.B. Rational Rose) erzeugte Diagramme sind leichter zu lesen als menschenerzeugte (v.a. wenn ich es zeichne). Trotzdem haben diese Tools ein...

<exkurs>
Problem: Die vom OO-Analyst gezeichneten Diagramme stellen Prognosen für eine effiziente programmatische Lösung der business cases dar. Bei der Umsetzung in code kann sich herausstellen, dass es anders als gezeichnet eben besser geht.
Die UML-Sichten müssten also neu gezeichnet werden. Dies läuft auf eine mehrfache Pflege von "source code" hinaus. Eine Lösung aus diesem Dilemma wären roundtrip engineering tools, wo aus Source code UML Modelle generiert werden können. Dies erfordert aber einen hohen UML- und OO-Design-Tool Sachverstand.
</exkurs>


Für einen OO-Anfänger sind solche Tools wie Rational Rose sicher nichts. Ich benutze Rose seit 2 Wochen, aber nur Teile und bislang mehr intuitiv. Hat meine Erwartungen übererfüllt, aber ich beschäftige mich schon länger mit diesem OO/UML Zeugs und ich war skeptisch.

Aber OOD/A im Kopf? Dadurch verliert man dieses wichtige Dokumentations-Feature. Überhaupt... Mein Kopf reicht für meine OO-Aufgabenstellungen nicht aus. Ich bezweifele stark, dass der Kopf von irgendjemand für OO/A Aufgabenstellung, die eine gewisse Trivialitätsschranke überschreiten, ausreicht.
Ich meine: Ein Warenkorb besteht aus einer Menge an zu kaufenden Items. O.k.. Aber jemand einen Vorschlag für die Objektmässige Darstellung des Spielplans der EM 2004 in Portugal. Im Kopf?
Ich nehm dafür lieber Rational Rose.

Gruß Axel

Semeaphoros:
Axel: Du hast etwas ganz wichtiges Ueberlesen:

für KLEINE SACHEN

Du redest definitiv nicht von kleinen Sachen, wenn Du von Team(s) redest.

Hernan Cortez:

--- Zitat von: Semeaphoros am 28.04.04 - 10:04:48 ---für KLEINE SACHEN

--- Ende Zitat ---

Hi,

Das müssen aber schon sehr kleine Sachen sein.
Hier ist eine Sache, die ich neben der Arbeit, mit mir selber ausmache:
Das ist eine statische Klassenstruktur der Objekte des Spielplans wie ich sie für ein Tippspiel benötige. Das Ergebnis von 2 Stunden mässig fokussierter Arbeit (inklusive nachdenken) von 1 tio loco:



Wenn ich es nicht in Rose (oder mit Papier und Bleistift) persistiert hätte, hätte ich es heute vergessen.
Und das ist bei weitem noch nicht fertig. Im Grunde fehlen da sogar Kommentare (und zwar dringend).
Bevor ich anfange zu coden, brauche ich sowieso ausserdem noch eine dynamisches Modell für bestimmte Anwendungsfälle.

Wenn Leute eine Relationale Datenbank neu planen, malen sie doch auch ein Entity Relationship Model. Warum soll das mit Objekten anders sein ???

Ich bleibe dabei: Gezeichnetes UML ist für reale Welt OO unverzichtbar.
Alles andere ist a-bit-to-rapid-application-development mit den nachteiligen Folgen:
- unzureichende Dokumentation
- oft fällt einem während des Zeichenprozesses ein, wie man es besser machen kann

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete