0

我可以使用此模板方法模式将逻辑与日志记录和异常处理分开，还是“不好的做法”？

例如我有这个代码：

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().

我想知道它是否值得，它是否是“坏习惯”。

4

1 回答 1

1

如果该模式解决了您遇到的问题，并且您确信以后不会引起更多问题，那么我认为没有任何问题。

我个人的偏好是装饰器模式。在“模板”版本中，其中Childextends 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做任何其他你想让它做的事情。客户永远不需要知道它拥有哪一个。

更喜欢关联而不是继承。

于 2016-05-28T14:22:08.947 回答