Inhalt Abbildung PDF Source OO-Designkurs
 |<    <     >    >|  Generated by CoCoDiL

2.4 Vereinfache Bedingungen

2.4.1 Ersetzte verschachtelte Bedingungen durch Guard Clauses

Wie kann ich folgende Methode vereinfachen: 

double getPayAmount(){
   double result ;
   if (_isDead) result = deadAmount();
   else {
        if (_isSeparated) result = separatedAmount();
        else {
             if (_isRetired) result = retiredamount();
             else result = normalPayAmount();
        };
   }
   return result;
 };

Hier die einfache Lösung: 

double getPayAmount(){
  if (_isDead) result deadAmount();
  if (_isSeparated) return separatedAmount();
  if (_isRetired) return retiredAmount();
  return normalPayAmount();
};

Refactoring Replace Nested Conditional with Guard Clauses

2.4.2 Ersetzte Bedingungen durch Polymorhpismus

In vielen Fällen sind verschachtelte Bedingungen ein Zeichen für fehlende Klassen. Siehe bitte folgendes Beispiel: 

class Employee ...
    private int _type;
    static final int ENGINEER = 0 ;
    static final int SALESMAN = 1 ;
    static final int MANAGER = 2 ;
...
int payAmount(){
       switch (_type){
          case ENGINEER:
             return _monthlySalary ;
          case SALESMAN:
             return _monthlySalary + _commission ;
          case MANAGER:
             return _monthlySalary + _bonus
          default:
             throw new RuntimeException("Incorrect Employee");
        }
    }

In relationalen Datenbanken ist es in Ordnung eine Tabelle Employee mit einer Spalte Type zu definieren. In rel. Datenbanken wird nicht das Verhalten sondern nur die Struktur eines Objekts gespeichert. Klassen sollten aufgrund des Verhaltens (Methoden), und nicht aufgrund ihrer Struktur (Attribute) entworfen werden. Es lohnt sich die Klassen ENGINEER, SALESMAN bzw. MANAGER anzulegen. Dabei gibt es 2 Möglichkeiten.


Abb. 2.14: Verwendung von Polymorphismus

Refactoring Replace Type Code with State/Strategy, Replace Type Code with Subclasses.

2.4.3 Führe Null Objekt ein

Viele Bedingungen überprüfen, ob ein Empfänger einer Methode überhaupt vorhanden ist.


Abb. 2.15: Beispiel ohne Nullobjekt

Die Einführung von NullObjekten ermöglicht es auf andauernde Fragen ob ein Attribut gesetzt sind zu verzichten. Das NullObjekt hat i.a. genau die gleichen Sclhnittstelle wie das entsrechende "reales" Objekt. Allerdings laufen die Methoden i.a. ins Leere oder geben ein NullObjekt einer anderen Klasse zurück. Die untere Lösung zeigt auch das Prinzip der Lazy Initialisation. Der Wert des Attributs mieter in der Klasse Haus, kann nie nil werden. Es ist immer garantiert, daß ein (Null) Mieter gesetzt ist. Alle Methoden der Klasse Haus, die sich auf den Mieter beziehen, können auch ausgeführt werden.


Abb. 2.16: Beispiel mit Nullobjekt

Refactoring Introduce Null Object

Inhalt Abbildung PDF Source OO-Designkurs
 |<    <     >    >|  Generated by CoCoDiL