loswerden, wenn Aussagen Code-Design

Question

zu verbessern Wie kann ich das Design des unten stehenden Codes verbessern:

class Foo { 
    public Configuration configure() { 
     return new Configuration().withPropertyA().withPropertyB(); 
    } 
} 

class Configuration{ 


    private boolean propertyA = false; 
    private boolean propertyB = false; 

    public Configuration withPropertyA() { 
     this.propertyA = true; 
     return this; 
    } 

    public Configuration withPropertyB() { 
     this.propertyB = true; 
     return this; 
    } 

    public boolean hasPropertyA() { 
     return this.propertyA; 
    } 

    public boolean hasPropertyB() { 
     return this.propertyB; 
    } 

    ... 
} 

class Client{ 

public void someMethod(Configuration config) { 
    if (config.hasPropertyA() { 
     doStuffA(); 
    } 
    if (config.hasPropertyB() { 
     doStuffB(); 
    } 
    //... 
} 

} 

Ie, hält die Konfigurationsklasse einige Flags für den Anrufer (Client), die dem Anrufer sagen, was "Dinge" müssen konfiguriert werden. Der Client weiß, was für die einzelnen Flags zu tun ist, wenn sie gesetzt sind. Ich möchte die if-Anweisung in Client sowie das Konzept der einfachen Einstellung boolescher Flags in der Configuration Instanz loswerden. Können Sie einen eher "generischen" und objektorientierten Ansatz vorschlagen?

freundlichen Grüßen

Answer 1

können Sie verwenden, um die Strategiemuster. Jeder If wird zu einer Strategie, die doStuff mit eigener Logik implementiert. Wenn eine Eigenschaft (A, B ...) festgelegt ist, fügen Sie die Strategie zur Liste hinzu. Sie müssen nur auf die Strategien zur Schleife und führen sie, ohne ifs:

public class Foo { 
    public Configuration configure() { 
     return new Configuration().withPropertyA().withPropertyB(); 
    } 
} 

class Configuration { 
    Set<StuffStrategy> strategies = new HashSet<StuffStrategy>(); 

    public Configuration withPropertyA() { 
     strategies.add(new PropertyAStrategy()); 
     return this; 
    } 

    public Configuration withPropertyB() { 
     strategies.add(new PropertyBStrategy()); 
     return this; 
    } 

    public void executeStrategies() { 
     for (StuffStrategy strategy : strategies) { 
      strategy.doStuff(); 
     } 
    } 
} 

interface StuffStrategy { 
    public void doStuff(); 
} 
class PropertyAStrategy implements StuffStrategy { 
    @Override 
    public void doStuff() { 
    } 
} 

class PropertyBStrategy implements StuffStrategy { 
    @Override 
    public void doStuff() { 
    } 
} 

class Client { 
    public void someMethod(Configuration config) { 
     config.executeStrategies(); 
    } 
} 

Answer 2

Es sieht aus wie Sie eine pitfall schreiben

versuchen in diesem Fall etwas flexibler in der Gestaltung mit .... wie ein enumerator ... einen Blick auf diese:

Beispiel:

public class Foo { 
    public Configuration configure() { 
    return new Configuration(Config.A); 
    } 
} 

class Configuration { 

enum Config{ 
A,B, NONE} 

    private Config propertyConfig = Config.NONE; 

    public Configuration(Config a) { 
    propertyConfig=a; 
    } 


    public Config getConfig() { 
    return this.propertyConfig; 
    } 

    ... 
} 

class Client { 

    public void someMethod(Configuration config) { 
     switch (config.getConfig()) { 
    case A: 
     System.out.println("a config"); 
     break; 
    case B: 
     System.out.println("b config"); 
     break; 

    default: 
     break; 
    } 
    // ... 
} 

} 

Answer 3

Ich glaube nicht, dass Sie eine OO Ansatz finden können als das, was Sie currenly vor allem tun, wenn Sie mehrere Parameter haben, in der Tat Das ist das bekannte Designmuster Builder. Das Beste, was Sie tun können, ist, dieses Muster richtig zu implementieren, indem Sie Ihr Objekt Configuration unveränderlich machen. Nur Ihre Builder-Klasse sollte in der Lage sein, eine Instanz von Configuration zu erstellen. Ihr Builder sollte eine veränderbare statische innere Klasse mit einer build()-Methode sein, die eine unveränderliche Configuration-Instanz zurückgibt.