Ontwerp Richtlijnen

Ontwerp fases

Conceptuele perspectief: concepten benoemen, daar taken aangeven en hun onderlingen interactie aangeven
Pecificatieperspectief: uitwerking interfaces van de klassen
Implementatieperspectief: code toevoegen aan het geheel

Begin met een algemene probleem beschrijving van het geheel.
Benoem de patronen die daar in aanwezig zijn.
Begin met het patronen die de context bepalen voor anderen patronen.
Voeg die patronen daarna toe.
Voeg daarna de ontbrekende patronen toe. (plus de gene die je alter ondenkt hebt)
Maak dan het ontwerp specifiek voor jouw probleem
Benoem nu (pas) de diverse klasses

Ontwerp criteria

Afwezigheid van redundantie tussen methoden
Overzichtelijkheid
Princiepe van hoge cohesie (samenhang)
Princiepe van lage koppeling
Princiepe van gescheiden verantwoordelijkheden.
Intuitie

Ontwerpstrategieen- en regels

Hou rekening met veranderingen
Ontwerp vanuit de context
Ontwerp naar interfaces
Verberg variatie
Geef de voorkeur aan compositie boven overerving
Once and only one rule
Stel de beslissing hoe objecten gecreerd moeten worden uit
Breid software uit (overerving) zonder het te veranderen

Egoistische classen

(Geen onderdeel van de leerstof)

Is aantrekkelijk [list]
Doelgericht
Verkrijgen
Begrijpbaar
Betrouwbaar

[*] Werkt uit de doos [*] Eenvoudige interfaces doen veel [*] Leerbaar in kleine stapjes [*] Heeft wijzegingsmeganismen voor toekomstige uitbreidingen [*] GRATIS [*] Comes with the WINNING TEAM [/list]

Overig

Object are things with well defined responsibilities.
Objects are responsible for themselves.
Encapsulation means any kind of hiding. [list]
Data-hiding
Class hiding (behind an abstract class or interface)
Implemention hiding

[*] Abstract out variations in behavior and data with commonality variablity analysis. [*] Think of inharitance as a method of conceptualizing variation, not for making special cases of existing objects. [*] Keep variations in a class decoupled from other variations to the class. [/list]

Navigation

Table of contents