Genau so ist es, und mehr Grips zu investieren, hat noch nie geschadet  

Es ist tatsächlich so, dass man Objekte in der Regel nicht einfach aus dem Handgelenk schüttelt. Die zwangsweise bessere Planung führt zu besserem Code (was ja eigentlich eine Binsenwahrheit ist und nicht wirklich OO-spezifisch) und damit zu späterem Profit.

Und genau das ist der springende Punkt: selbst die beschränkten Möglichkeiten von OO in LS genügen, um davon profitieren zu können, nebst der Vorbereitung für die Zukunft, wie Du das weiter oben sehr schön dargestellt hast.

Richtig, es braucht mehr Planung, ein Prozess kann nützlich sein, es muss aber nicht unbedingt ein bestimmter sein. 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.

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

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

grossartiger Grusel to deepen your angst

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.

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

für KLEINE SACHEN

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