Refactoring-Code mit zu vielen Switch-Fällen

Question

Ich habe eine Anwendung geerbt, die einige Refactoring benötigt. Das Folgende bereitet mir Kopfschmerzen. Die Original-Quellcode hat zu viele Schalter Fälle wie folgt aus:

class Girl { 
    //... 
    void traditionalMakeUp() { 
     switch (type) { 
      case FRENCH: 
       frenchMakeUp(); 
       break; 
      case AFRICAN: 
       africanMakeUp; 
       break; 
      case NORWEGIAN: 
       norwegianMakeUp(); 
       ..... 

      case KOREAN: 
       koreanMakeUp(); 
       ..... 
     } 
    } 
} 

Ich versuche es so Refactoring:

abstract class Girl { 
    //... 
    abstract void makeUp(); 
} 

class French extends Girl { 
    void makeUp() { 
     // makeUP 
    } 
} 
class African extends Girl { 
    void makeUp() { 
     // makeUP 
    } 
} 
class Norwegian extends Girl { 
    void makeUp() { 
     // makeUP 
    } 
} 

// Somewhere in client code 
girl.makeUp(); 

Ist es der richtige Weg, es zu tun? Wenn ich nicht mehr als 20 Fälle in meinem Switch hätte, wäre das Strategie-Muster in Ordnung.

Darüber hinaus bin ich nur ungern 20+ Klassen hinzuzufügen, nur um das Strategie-Design-Muster zu passen. Gibt es einen anderen guten Weg, um es zu refaktorisieren?

Answer 1

Es gibt mehrere Möglichkeiten, ein solches Szenario zu refaktorieren.

Vererbung ist sicherlich eine Alternative hier zu betrachten. Je nachdem, wie tief die Hierarchie ist und ob Sie in der Hierarchie Hilfsklassen oder Zwischenklassen erstellen müssen, um gemeinsamen Code zu verwenden, würde ich die Zusammensetzung in Betracht ziehen.

Während was #makeUp unterscheidet sich je nach Art des Mädchens, vielleicht gibt es semantische Ähnlichkeiten, wo Sie kleine Einheiten von Code (Komponenten) bauen können, die Sie dann in einer komponentenartigen Art und Weise zusammenfügen können.

Answer 2

Es sieht aus, dass hier die Vererbung aufgerufen wird, abhängig davon, welche anderen Operationen/Schalter in Ihrer Anwendung für Girl basierend auf der Eigenschaft type existieren.

Wenn das der einzige Schalter ist, können Sie wie unten tun,

definieren ein ENUM Mädchen mit einer abstrakten Methode - Schmink() und dann diese Methode implementieren, genau dort für diesen Aufzählungstyp.

public enum Girl { 

    FRENCH { 
     public void makeUp() { 
      Utility.frenchMakeUP(); 
     } 
    }, 

    AFRICAN { 
     public void makeUp() { 
      Utility.africanMakeUP(); 
     } 
    }, 

    NORWEGIAN { 
     public void makeUp() { 
      Utility.norwegianMakeUP(); 
     } 
    }, 

    KOREAN { 
     public void makeUp() { 
      Utility.koreanMakeUP(); 
     } 
    }; 

    public abstract void makeUp(); 

} 

Ihre Utility-Klasse sieht so aus.

public class Utility { 

    public static void frenchMakeUP() { 

    } 

    public static void africanMakeUP() { 

    } 

    public static void norwegianMakeUP() { 

    } 

    public static void koreanMakeUP() { 

    } 

} 

Client-Code

Girl girl = Girl.FRENCH; 
girl.makeUp(); 

Sie können in Abhängigkeit von mehreren Utility-Klassen organisieren, wie viele Funktionalitäten existieren und wie gemeinsame Funktionalität heißt Anruf zu kombinieren, Utility.koreanMakeUP() von mit in makeUp() weiter organisiert werden kann.

Answer 3

Ich würde eher Komposition für Mädchen hier und Erbschaft für das Make-up machen. Abhängig von Ihrer Domain kann es für ein französisches Mädchen in Ordnung sein, African Makeup zu tragen. Lassen Sie ein Mädchen ein Objekt vom Typ MakeUp enthalten.

Dann würde ich so etwas wie:

public class FrenchMakeUp extends MakeUp 
{ 
    @Override 
    public void apply(){...} 
} 

public class Girl 
{ 
    public void makeUp(MakeUp makeUp) 
    { 
     makeUp.apply(); 
    } 
} 

Im Client-Code:

girl.makeUp(new FrenchMakeUp()); 

Dies ist näher an Ihren versucht refactor sein, aber es nicht die Entscheidungsfindung lösen. Vielleicht könnten Sie eine Karte haben, die Ihnen hilft, den richtigen Makeup-Typ zu wählen.