テンプレートメソッドパターンを使用したロギングとロジックの分離

Question

ロギングおよび例外処理とは別のロジックにこのテンプレートメソッドパターンを使用することができますか？「悪い習慣」ですか？

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(); 
} 

そして、私の子クラス：

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

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

私は方法doEat()とdoSleep()の異なる実装を持っていないでしょう

は、例えば、私はこのコードを持っています。

私はそれが価値があるかどうか、それが「悪い習慣」であるかどうかを知りたいです。

Answer 1

パターンが問題を解決し、後でそれ以上の問題を引き起こすことはないと確信している場合、私は何の問題も見ません。

私の個人的な好みは、ここではデコレータパターンです。 ChildがParentになる「テンプレート」バージョンでは、ロギングの動作は実際にはロジックから分離されておらず、隠れているだけです。唯一の利点は、複数のサブタイプParentで再利用できることです。彼らが本当に分かれているということは、あなたが知りたいと思っているクライアントがいなくても、どちらかを独立して変えることができるということです。

その後

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

、ロギング用：：これは、「デコ」のバージョンが動作するかもしれない方法である

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 
     } 
    } 
} 

今ロギング動作は、「食べる」動作から完全に分離されています。ログにはMyBehaviourが記録され、ログに記録されないMyBehaviourにすることができます。さらに、MyBehaviourにすることができます。クライアントは、どれがそれを持っているかを知る必要はありません。

Prefer association over inheritance.