2016-05-28 3 views
0

Darf ich dieses Vorlagenmethodenmuster für separate Logik von Protokollierung und Ausnahmebehandlung verwenden oder ist es "schlechte Praxis"?Getrennte Logik von der Protokollierung über das Vorlagenmethodenmuster

Zum Beispiel habe ich diesen Code:

public abstract class Parent { 
    private final Logger log = LoggerFactory.getLogger(getClass()); 

public void eat() { 
    try { 
     doEat(); 
    } catch (SomeException1 e) { 
     log.debug("some text"); 
     throw new CustomException1(); 
    } 
} 

protected abstract void doEat(); 

public void sleep() { 
    try { 
     doSleep(); 
    } catch (SomeException2 e) { 
     log.debug("some text"); 
     throw new CustomException2(); 
    } 
} 

protected abstract void doSleep(); 
} 

Und mein Kind Klasse:

public class Child extends Parent { 
@Override 
protected void doEat() { 
    //some logic 
} 

@Override 
protected void doSleep() { 
    //some logic 
}} 

Ich würde nicht verschiedene Implementierungen von Methoden haben doEat() und doSleep().

Ich möchte wissen, ob es das wert ist und es ist "schlechte Praxis" oder nicht.

+2

Logging ist eine Querschnitt betreffen, und als solche wird unter Verwendung von typischerweise behandelt [AOP] (https://en.wikipedia.org/wiki/Aspect-oriented_programming). – jaco0646

Antwort

1

Wenn das Muster das Problem löst, das Sie haben, und Sie sind zuversichtlich, dass es später keine Probleme mehr verursachen wird, sehe ich kein Problem.

Meine persönliche Präferenz wäre hier für ein Decorator-Muster. In der Version "Template", wo ChildParent erweitert, ist das Protokollierungsverhalten nicht wirklich getrennt von der Logik, es ist nur versteckt. Der einzige Vorteil ist, dass es in mehreren Subtypen von Parent wiederverwendbar ist. Wenn sie wirklich getrennt sind, bedeutet das, dass Sie beide unabhängig voneinander ändern können, ohne dass der Kunde es wissen muss. Dies ist, wie eine "Decorator" Version funktionieren könnte:

public class Thing implements MyBehaviour { 
    @Override 
    public void eat() { 
     //some logic 
    } 
} 

Dann wird für die Protokollierung:

public class LoggingThing implements MyBehaviour { 
    public MyBehaviour delegate; 

    public LoggingThing(MyBehaviour delegate) { 
     this.delegate = delegate; 
    } 

    @Override 
    public void eat() { 
     try { 
      delegate.eat(); 
     } catch (MyException e) { 
      // extra behaviour 
     } 
    } 
} 

nun das Logging-Verhalten von dem "essen" Verhalten völlig getrennt ist. Sie können eine MyBehaviour haben, die Protokolle, Sie können eine haben, die nicht protokolliert, und Sie können eine haben, die jede andere Sache tut, die Sie tun möchten. Der Kunde muss nie wissen, welchen er hat.

Prefer association over inheritance.

Verwandte Themen