类中所有方法开头均有相同if判断条件，可使用什么设计模式优化？

方案1：模板方法模式（最贴合需求的设计模式） #

该模式可以把公共判断逻辑统一收拢到公共执行流程中，业务代码只需要关心核心逻辑即可，两种常用实现形式：

• 类继承实现：
  定义抽象父类封装带前置判断的执行入口，子类仅实现核心业务逻辑，适合同类业务的多实现场景

// Java示例，其他语言逻辑通用
public abstract class BaseService {
    protected boolean locked;

    public final void execute() {
        // 公共前置判断全局统一维护
        if (locked) {
            return;
        }
        // 调用子类自定义业务逻辑
        doBusiness();
    }

    protected abstract void doBusiness();
}

• 同一个类内封装通用执行器：
  不需要额外继承父类，适合单个类内部多个方法需要加前置判断的场景

// Java示例，用函数式接口传业务逻辑
private <T> T runWithLockCheck(Supplier<T> businessLogic) {
    if (locked) {
        return null;
    }
    return businessLogic.get();
}

// 业务方法调用示例
public void businessMethod1() {
    runWithLockCheck(() -> {
        // 直接写业务逻辑即可，无需重复写判断
        return null;
    });
}

方案2：装饰器模式 #

如果不想用继承破坏原有类的结构，可以用装饰器封装公共判断逻辑，把原始业务对象包装在装饰器中，调用时先走装饰器的前置判断，再执行真实业务方法，适合需要灵活给方法增减前置校验的场景。

方案3：切面编程（AOP，工程实践中最常用） #

如果项目支持AOP能力（比如Spring项目、Python装饰器、JS高阶函数都可实现），可以直接给需要加判断的8个方法加自定义标记，全局切面统一拦截所有带标记的方法，执行前先判断locked状态，状态为真直接返回，完全不需要修改业务方法的原有代码。
Python实现示例：

def lock_check(func):
    def wrapper(self, *args, **kwargs):
        if self.locked:
            return
        return func(self, *args, **kwargs)
    return wrapper

# 业务方法仅需要加一个装饰器即可
@lock_check
def business_method1():
    # 直接写业务逻辑，不需要加任何判断
    pass

方案4：公共方法抽取（最轻量的快速实现） #

如果场景非常简单不想引入复杂模式，也可以把判断逻辑封装成一个私有公共方法，每个业务方法开头直接调用即可：

private boolean checkLocked() {
    return locked;
}

// 业务方法开头仅需要写一行调用
if (checkLocked()) return;

虽然还是要每个方法加一行调用，但后续如果判断逻辑需要修改（比如加日志、调整判断规则）只需要改这一个公共方法，也比重复写8遍判断逻辑的可维护性高很多。

内容的提问来源于stack exchange，提问作者André Kuljis