OOP Vorgehen

[Ook!]

Hallo!

Ganz allgemein:
Wie geht Ihr vor, wenn eine Aufgabe gestellt wird, die objektorientiert gelöst werden soll?
Zeichet Ihr ein Klassendiagramm? Einfach anfangen und ausprobieren?

Bei kleineren Aufgaben fange ich einfach an und komme dann eigentlich auch zu einem mehr oder weniger guten Ergebnis, bei größeren Aufgaben mach ich mir vorher schon Gedanken und schreibe alles mit Zettel und Stift auf

Gruß
Felix

 

[Elderan]

Hallo,

Original von Ook!
Wie geht Ihr vor, wenn eine Aufgabe gestellt wird, die objektorientiert gelöst werden soll?

Die gewöhnlichen Aufgaben die man gestellt bekommt, sind so primitiv zu lösen, dass man die Klassenstruktur sofort erkennt.

Alles andere sind keine 'Aufgaben', sondern eher Projekte.

Für größere Projekte, also _richtige_ Applikationen die auch was sinnvolles machen (und etwas umfangreicher sind), ist das erstellen von Klassendiagrammen extrem sinnvoll und wichtig.
Persönlich fange ich meistens mit einem Use-Case Diagramm an, dadran kann oft schon gut die groben 'Bereiche' des Programmes erkennen.
Diese Bereiche kann man dann immer feiner gliedern bis man irgendwann beim Klassendesign ankommt.


Ansonsten ist das meistens alles Erfahrung und ich weiß nun nicht, was du unter 'größere Aufgaben' verstehst. Die, die man in der Schule/Uni bekommt sind eigentlich immer sehr bescheiden, oder aber ein großes Projekt über einen längeren Zeitraum (also Diagramme, die sind an der Uni dann meistens eh Pflicht)

Hoffe konnte helfen.

Was sonst noch ganz gut ist, für leute die neu in der OO sind: Praxisbuch Objektorientierung (OpenBook)

 

[beavisbee]

also gerade wenn es vieleicht auch darum geht, ein Projekt unter mehreren Leuten aufzuteilen (so ist's bei uns an der FH: Projekte in 3er- oder 4er-Gruppen, auf dass man teamfähig wird... ), kommt man um eine gute Planung nicht drum rum...

sicherlich passiert es des öfteren mal, dass man während des Programmierens noch andere bessere Ideen bekommt und die Strukturen sich manchmal noch ein wenig ändern, bestimmte mehrfach genutzte Sachen in eigene Klassen ausgelagert werden (damit der Prof. auch sieht, wie toll man die Vererbung beherrscht ) - aber zumindestens ein grobes Konzept in Form von stapelweise Skizzen / wilde Schmierereien (vom Brainstorming) bis zu UML-Diagrammen sollte am Anfang eines jeden Projektes schon stehen, damit man eine logische Gliederung bekommt und die Arbeit sinnvoll verteilen kann...

Bei unserer Gruppe sieht's dann z.B. meistens so aus, dass ich die Planung übernehme, die Haupt-Aufgaben auf die beiden Kommilitonen verteile und mich selbst um die Binde-Glieder zwischen den verschiedenen einzeln laufenden Aufgaben kümmere, bei beiden Kommilitonen schaue, in wie weit meine Planung aufgeht und wo mir noch Besserungen einfallen und mich um die Qualitätssicherung kümmere (sämtliche Fälle überlegen, was wo in irgendeiner Form schief gehen könnte, Test-Programme zum Prüfen auf evtl. Fehler --> Ausgabe des Testprogs wandert ins Protokoll...)

ohne eine gewisse Planung geht da nichts...

 

[t3rr0r.bYt3]

Die gewöhnlichen Aufgaben die man gestellt bekommt, sind so primitiv zu lösen, dass man die Klassenstruktur sofort erkennt.

Trotzdem können auch dabei UML-Diagramme sehr nützlich sein. Ich schmier die gerne auf ein whiteboard und kann dann beim implementieren nen Blick drauf werfen.

Solange ich die Klassen und ihre Beziehungen zum Großteil im Kurzzeitgedächtnis überblicken kann, ist Planung nicht zwingend notwendig. Sobald das nicht mehr der Fall ist, ist sie Pflicht. Nachdenken kostet später sowieso mehr Zeit als Nachschaun, und es ist fehleranfällig.