Zerlegung in Teile

• Grundobjekte in betrachteten UML-Diagrammen:
  • liefern Klassen
    • Class
    • Interface
    • Object
  • werden abgeleitet von gemeinsamer Oberklasse UmlElement
  • Grundstruktur
    • 
  • zusätzlich Methoden zum Zugriff auf die Felder (setName, getName)
  • Alternative für Object
    • type zeigt auf eine Class
    • braucht dann keine eigene Feldliste
    • Vorteil: automatischer Abgleich mit seiner Class
    • Nachteil: Objekt nur möglich mit entsprechender Class
• Datenfelder und Methoden:
  • Grundidee: sind selbst Objekte entsprechender Klassen (Field, Method)
  • Gemeinsamkeiten herausgelöst in Oberklasse Member
  • Grundstruktur
    • 
  • Member abgeleitet von UmlElement (wie Class etc.) wegen Gemeinsamkeiten
    • hat Feld name
    • wird im Diagramm gezeichnet
    • kann editiert werden
    • aber: ist kein selbständiges Objekt im UML-Diagramm
  • Method nutzt für die Parameterliste selbst Field als Teile
    • Vorteil des Herausgliederns
    • Class mehrstufig zergliedert
    • 
• Implementierung Field:
  • nur langweilige Zugriffsmethoden

    • public String getValue() {
        return value;
      }
      
      public void setValue(String newValue) {
        value = newValue;
      }

  • typisch für Klassen, die i.w. Daten enthalten
  • Property
    • Datenfeld mit set- und get-Methode
    • von Entwicklungsumgebungen unterstützt
• Pattern Whole-Part:
  • Pattern-Typ Structural
  • Problem
    • ein Objekt (Whole) besteht aus einer Anzahl verschiedener Teile (Parts)
    • Teile sind selbst recht kompliziert
  • Lösung
    • modelliere Teile als eigene Klassen
    • füge ggf. Liste von Parts in Whole ein
    • Whole kapselt die Parts nach außen, falls sinnvoll
  • Konsequenzen
    • Teile können in mehreren Klassen verwendet werden (+)
    • Komplexität der Whole-Klasse sinkt (+)
    • Zahl der Klassen steigt an (-)