Design-Richtlinien
Zero Tolerance
Akzeptieren Sie zu keiner Zeit Elemente welche mit „Unschönheiten“/offenen Punkten behaftet sind (das bereinigen wir dann später ...). Einerseits werden Sie die Unschönheit vermutlich nie bereinigen und andererseits kann sie zu unbeabsichtigten Quereffekten/Problemen in ihrem Code führen.
Einsatz von Design Patterns
Prüfen Sie bei jeder Aufgabenstellung ob Muster eingesetzt werden können. Durch den Einsatz von Patterns gelangen sie zu einer verbesserten Qualität (die Patterns sind ja vielfach erprobt), sie selbst erlangen mehr Sicherheit darüber ob ihr Entwurf gut ist und zu guter Letzt erhöhen sie dadurch auch die Lesbarkeit und Verständlichkeit des Codes.
Eindeutigkeit / Abgrenzbarkeit
Jedes Element ihres Designs sollte eine konkrete Aufgabe erfüllen. Schaffen Sie keine Elemente welche für eine bestimmte Funktionalität zuständig sind und daneben noch andere Dinge ausführen. Dieses Prinzip sollte sich auch in der Bennenung des Elements (Komponenten, Klasse, Methode, Attribut, etc.) niederschlagen. Benennen Sie die Elemente genau nach dem was Sie wirklich machen.
Wenn Sie die obgenannen Ratschläge befolgen, werden Sie auch dazu kommen klar abgegrenzte Elemente zu definieren.
Wenn Sie die obgenannen Ratschläge befolgen, werden Sie auch dazu kommen klar abgegrenzte Elemente zu definieren.
Don't repeat yourself (DRY)
Versuchen Sie sämtliche Wiederholungen zu vermeiden bzw. durch Refactoring zu eliminieren.
Ueberlegen Sie überall wo sie "etwas ähnliches" antreffen, ob sie diese ähnlichen Elemente nicht in einem Element zusammenfassen können.
Dies gilt z.B. auch für parallele Klassenhierarchien.
Ueberlegen Sie überall wo sie "etwas ähnliches" antreffen, ob sie diese ähnlichen Elemente nicht in einem Element zusammenfassen können.
Dies gilt z.B. auch für parallele Klassenhierarchien.
Refactoring
Refactoring bezeichnet die laufende Ueberarbeitung/Verbesserung von Code.
Es gibt sehr wenig Entwickler (ich kenn keine), welche im ersten Versuch perfekten Code schreiben. Perfekter (oder zumindest sehr guter) Code wird erst durch verschiedene Ueberarbeitungen erreicht. Damit Sie sich aber jederzeit getrauen, den bestehenden Code umzuschreiben (weil z.B. eine "bessere" Lösung gefunden worden ist) müssen Sie entsprechende Vorkehrungen (z.B. UnitTesting gem. KentBeck) treffen.
Es gibt sehr wenig Entwickler (ich kenn keine), welche im ersten Versuch perfekten Code schreiben. Perfekter (oder zumindest sehr guter) Code wird erst durch verschiedene Ueberarbeitungen erreicht. Damit Sie sich aber jederzeit getrauen, den bestehenden Code umzuschreiben (weil z.B. eine "bessere" Lösung gefunden worden ist) müssen Sie entsprechende Vorkehrungen (z.B. UnitTesting gem. KentBeck) treffen.
Kapselung
Kapseln Sie sämtliche Elemente ein, welche nicht direkt zu Ihrer Applikation gehören; ausgenommen vielleicht Komponenten aus ihrer Entwicklungsumgebung.
Wenn Sie Elemente einkapseln, dann tun Sie das aus der Sicht der Verwendung durch ihre Applikation. Ich habe schon Einkapselungen gesehen, bei welchen "einfach" die durch das Drittprodukt angebotenen Methoden 1:1 in die Kapselungsklasse übernommen wurden. Ueberlegen Sie sich vielmehr, welche Dienste ihre Applikation designen sie die öffentliche Schnittstelle der Kapselungsklasse entsprechend und codieren Sie hinterher den Zugriff auf die Methoden der eingekapselten Elemente.
Wenn Sie Elemente einkapseln, dann tun Sie das aus der Sicht der Verwendung durch ihre Applikation. Ich habe schon Einkapselungen gesehen, bei welchen "einfach" die durch das Drittprodukt angebotenen Methoden 1:1 in die Kapselungsklasse übernommen wurden. Ueberlegen Sie sich vielmehr, welche Dienste ihre Applikation designen sie die öffentliche Schnittstelle der Kapselungsklasse entsprechend und codieren Sie hinterher den Zugriff auf die Methoden der eingekapselten Elemente.
Gesetz von Demeter
Das "Gesetz von Demeter" sagt aus, dass eine Methode eines Objekts nur Methoden von
- sich selbst
- Parametern der Methode
- in der Methode erzeugten Objekten
- Komponenten-Objekte (der Klasse)
Validierung nur in der Business-Logik
Führen Sie sämtliche Validierungen (mit Ausnahme von "Eingabekontrollen" auf Datentyp-Ebene) in der Business-Logik ihrer Applikation durch. Sie vermeiden dadurch, dass sie dieselben Validierungen mehrfach codieren (und warten) müssen.
Naming
Sämtliche Elemente (Komponenten, Klassen, Methoden, Attribute) sollten sprechende Namen aufweisen. Diese Namen sollten Aussagen, was das Elemente genau macht bzw. wozu es da ist. Und das Element sollte auch genau das tun (und nichts anderes).
Benützen Sie wo immer möglich Fachausdrücke. Pre- und Postfixe für Attributbezeichnungen gehören m.E. mit wenigen Ausnahmen der Vergangenheit an. Die heutigen IDE-Umgebungen zeigen Ihnen auf "Knopfdruck" die erlaubten Variabeln (bzw. diejenigen des korrekten Typs) an.
Als Ausnahmen hierzu würde ich Präfixe bei Methoden-Paramtern (um Sie von allfälligen Attributnamen zu unterscheiden) sowie Präfixe zur Kennzeichnung von Pointern bezeichnen.
Benützen Sie wo immer möglich Fachausdrücke. Pre- und Postfixe für Attributbezeichnungen gehören m.E. mit wenigen Ausnahmen der Vergangenheit an. Die heutigen IDE-Umgebungen zeigen Ihnen auf "Knopfdruck" die erlaubten Variabeln (bzw. diejenigen des korrekten Typs) an.
Als Ausnahmen hierzu würde ich Präfixe bei Methoden-Paramtern (um Sie von allfälligen Attributnamen zu unterscheiden) sowie Präfixe zur Kennzeichnung von Pointern bezeichnen.