Software-Design

[mikesc]

Hallo zusammen,

hier sind ja einige sehr versierte Leute unterwegs die hoffentlich schon ein ähnliches Problem hatten oder irgendwo gelernt haben wie es richtig geht ;)
Beim Programmieren gehe ich meistens so vor, dass ich mir die erstbeste Ad-hoc-Lösung zusammenhacke, darauf dann aufbaue, und sobald es zu wüst wird eben Refactoring ansteht. Das führt letztendlich leider oft zu schlecht zu durchschauenden/erweiterbaren Systemen mit unendlich vielen Abhängigkeiten.
Zwar hab ich schon ein paar mal versucht mir vor der Implementierung ein Klassendesign zu erarbeiten, leider mit mäßigem Erfolg, letzlich musste ich dann bei der Implementierung soviel umstellen, dass ich wieder am Anfang war.
Mich würde interessieren wie ihr vorgeht wenn ihr eine Problemstellung in ein Design (oder direkt in eine Implementierung) umsetzen wollt, ob ihr strukturiert vorgeht, usw. Mir geht es dabei vor allem um ein grobes Design der Klassen und deren Abhängigkeiten. Ich würde mich auch über Literaturempfehlungen zu dem Thema sehr freuen.

Grüße
Michael

[jgl]

Also ich habe gemerkt, dass es ganz hilfreich ist, sich einen groben Plan zu machen.
Alle Klassen so erweitrungsfähig zu machen wie es geht, damit man bei Bedarf erweitern kann.
Macht zwar manchmal etwas mehr arbeit, aber rentiert sich ungemein ;) ...
Eine gemeinsame Basiklasse ist immer anstrebsam.

Just my 2 cents.

[Despotist]

Zwar hab ich schon ein paar mal versucht mir vor der Implementierung ein Klassendesign zu erarbeiten, leider mit mäßigem Erfolg, letzlich musste ich dann bei der Implementierung soviel umstellen, dass ich wieder am Anfang war.

Ich denke dass man mit Vorausplanung einige aber nicht alle Dinge berücksichtigen kann. Die Summe der Änderungen sollte aber kleiner sein als wenn du Ad-hoc startest. Das wird natürlich mit Erfahrungen und genauer Spezifikation besser. Und wenn das Design darauf ausgelegt ist sollten spätere Erweiterungen kein Problem sein.
Andererseits ist die Frage warum du dein Design im Nachhinein deinen Vorstellungen anpasst und nicht deine Vorstellungen dem Design? Vielleicht ließen sich die Änderungen auch mit vorhandenen Mitteln unterbringen?

Mich würde interessieren wie ihr vorgeht wenn ihr eine Problemstellung in ein Design (oder direkt in eine Implementierung) umsetzen wollt, ob ihr strukturiert vorgeht, usw.

Für alle wichtigen und/oder großen/komplexen Projekte erstelle ich mir ein Klassendiagramm und versuche die offensichtlichen Anforderungen unterzubringen. Aber um das besonders OOP-elegant zu machen und "exotische" Design-Patterns anzuwenden fehlt mir die Erfahrung und Geduld ;).

Eine gemeinsame Basiklasse ist immer anstrebsam.

Soweit ich weiß widerspricht das aber "gutem" Design wie z.b. die Objectklassen in MFC oder Java. Zumindest sehen das einige kontrovers.

Macht zwar manchmal etwas mehr arbeit, aber rentiert sich ungemein

Es ist IMMER mehr Arbeit zumindest am Anfang aber ich denke auch dass man diese Zeit später mehrfach einspart. Und diese Gedanken muss man sich so oder so machen also warum nicht am Anfang wo man sich nur darauf konzentriert? Ich finde es immer einfacher in einem vorhandenen großen Gerüst kleine Sachen einzubauen als wenn man mit kleinen Sachen beschäftigt ist immer das Große Ganze im Hinterkopf behalten zu müssen.

Ich würde mich auch über Literaturempfehlungen zu dem Thema sehr freuen.

Grady Booch - "Objektorientierte Analyse und Design" ist zwar etwas älter und nicht mehr ganz aktuell gab mir aber einen guten Überblick.

[Chromanoid]

Also ich bin durchaus Fan von [rapid] Prototyping - allerdings ist das manchmal problematisch, wenn man den Prototypen präsentiert und dann die Abnehmer meinen es wäre damit schon getan - schließlich "funktioniert" es ja...

Wichtiger als ein klassendiagramm oder andere technisch orientierte pläne ist IMO eine genaue Anforderungsspezifikation. Denn erst wenn man die Anforderungen kennt, kann man eine gute Architektur dafür planen.

Wenn es vor allem um besseren code geht, könnte "Code Complete" von Steve McConnell auch etwas sein..

[Hanno]

Besser zu planen ist bestimmt eine Lösung, aber meiner Meinung nach meistens nicht die beste. Genauso würde ich Klassen nicht von vornherein flexibler machen als sie sein müssen.

Ich sehe das so:
- Das perfekte Design kriegt man vorher eh nicht hin, oft nicht mal ein gutes.
- Deswegen, und weil sich Anforderungen oft genug ändern können, sollte sich Code leicht ändern lassen.
- Gute Architektur beginnt damit, dass man jede einzelne Klasse gut designt. So kann man später (wenn man besser weiß, was man eigentlich braucht) die Architektur Stück für Stück anpassen, ohne dass zu viele Klassen von der Änderung betroffen sind.

Ich denke man kommt schon sehr weit, wenn man einige grundlegende Regeln beachtet:
- Law of Demeter einhalten
- Keine Basisklassen für gemeinsame Funktionalität! Stattdessen immer Komposition bevorzugen und Basisklassen nur verwenden um Interfaces zu definieren (bzw. in Java von Anfang an nur Interfaces verwenden).
- Keine Singletons, kein Zugriff auf statische Methoden (mit wenigen Ausnahmen). Stattdessen Dependency Injection.
- Abhängikeiten einer Klasse nicht in der Klasse selbst erzeugen. Auch hier Dependency Injection verwenden.

Das sind so ein paar Punkte, die relativ leicht umzusetzen sind. Wenn man einen Schritt weitergehen will kann man mit Test-driven Development arbeiten. Wenn man TDD korrekt anwendet, dann führt das fast automatisch zu einem besseren und wartbaren Design.

Falls du wirklich tief in das Thema TDD einsteigen willst kann ich dir folgende Bücher empfehlen:
- Test Driven Development. By Example
- Growing Object-Oriented Software, Guided by Tests

Generell zum Thema guten Code kann ich Clean Code empfehlen. Der Autor empfiehlt zwar auch TDD, aber das Buch hat unabhängig davon auch sehr gute Tipps.

[Zudomon]

Bei mir ist es auch so, dass ich einfach drauf los programmiere... da plane ich, was Code angeht, überhaupt nichts. Was am Ende raus kommt ist eher ein automatischer Prozess. Es wird halt immer hier und da verbessert und dadurch kommt nach und nach die endgültige Form. Kommentare existieren in meinem Code auch nicht, außer es handelt sich um Abkürzungen oder "Magic-Numbers".
Von OOP bin ich auch nicht gerade ein Fan und versuche es, wo es geht zu vermeiden. Auch die Nutzung von Pointer will ich in Zukunft noch stärker einschränken. Weil früher oder später haut es mir Exceptions rein. Die Suche danach kann dann unter Umständen sehr Zeitintensiv werden.

Ich denke, letztlich muss da jeder seinen Weg finden, wie man halt am besten voran kommt. :D

[kimmi]

Ich geh gern folgendermaßen vor:

• Probieren, um das Problem zu verstehen.
• Wegschmeißen der ersten Lösung.
• Ordentlich bauen, wenn das nicht klappt, siehe oben!
• Iterativ refactoren und einzelne Verantwortlichkeiten in Klassen auslagern. Nach einem Jahr blickt man es oft nicht mehr, was alles in der 2000 zeilen Klasse ging.

Dazwischen baue ich mir dann immer mal wieder einen Unittest, der mein gewünschtes Verhalten dokumentiert. Wie man sehen kan, bevorzuge ich den iterativen Ansatz. Meiner Erfahrung nach können Wasserfall-Architekturen oft nicht alles im voraus berücksichtigen und diesem Umstand sollte man Rechnung tragen.

Gruß Kimmi

[mikesc]

Danke an alle für die Anregungen, vor allem zu TDD, was sich wirklich sehr interessant anhört.

[Brainsmith]

Ich sehe die ganze Sache ziemlich genau so wie Kimmi..
Ich befolge strikt drei Regeln ind genau der Reihenfolge:

-make it work
-make it right
-make it fast

Das hat IMO den Vorteil, dass man unter Zeitdruck auch erstmal die "make it right"-Variante nehmen kann.
Allerdings mache ich mir auch bei allen Sachen, die ich schreibe, erstmal bei jeder Methode Gedanken darum, wo sie am besten hinpasst.

Bezüglich Basisklassen bin ich skeptisch.. Das muss man gut unter Kontrole haben, damit man nicht sogenannte Blobklassen (Klassen, die viel overhead haben, da mehrere, aber nicht alle, Klassen auf die gleichen Methoden zugreifen) erstellt.