$KK(Vereinfache Bedingungen) 
$KKK(Ersetzte verschachtelte Bedingungen durch Guard Clauses)

Wie kann ich folgende Methode vereinfachen: 

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

Hier die einfache Lösung:

$R(Source)

double getPayAmount(){
  if (_isDead) result deadAmount();
  if (_isSeparated) return separatedAmount();
  if (_isRetired) return retiredAmount();
  return normalPayAmount();
};
$R\
 
$R(Literatur)
 [i|Refactoring>refactoring] Replace Nested Conditional with Guard Clauses 
$R\


$KKK(Ersetzte Bedingungen durch Polymorhpismus)

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

$R(Source)
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");
        }
    }
$R\

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. 

* Die neuen Klassen sind Unterklassen der (jetzt abstrakten) Klasse Employee. 
* Verwendung des Rollenpatterns 

$B(Bilder,conditio.gif,Verwendung von Polymorphismus)

$R(Literatur)
 [i|Refactoring>refactoring] Replace Type Code with State/Strategy, Replace Type Code with Subclasses. 
$R\

$KKK(Führe Null Objekt ein)

Viele Bedingungen überprüfen, ob ein Empfänger einer Methode überhaupt vorhanden ist. 
 
$B(Bilder,nullobj1.gif, 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.  

$B(Bilder,nullobj2.gif,Beispiel mit Nullobjekt)

$R(Literatur)
 [i|Refactoring>refactoring] Introduce Null Object
$R\