采用Template Method设计模式的UML图是否违反Interface Segregation Principle？

我绘制了一张应用模板方法设计模式的UML图：

两个具体类在模板方法createTask和completeTask中共享大量逻辑，仅在具体实现上存在细微差异，因此我选用了模板方法设计模式。但其中一个具体类无需验证，故将抽象方法performValidations实现为空的void方法。请问这种情况是否违反接口隔离原则（Interface Segregation Principle）？还是允许将该抽象方法在具体类中留空实现？

首先明确：这种空实现的做法确实违反了接口隔离原则（ISP），同时也偏离了模板方法模式的设计初衷。

为什么违反ISP？ #

ISP的核心是「客户端不应该依赖它不需要的接口」——你的这个具体类完全不需要performValidations这个行为，却被迫实现它（哪怕是空实现），这就属于让类依赖了自身用不上的方法，直接违反了ISP的核心要求。

空实现的潜在问题 #

• 代码冗余：无意义的空方法会增加代码噪音，降低整体可读性
• 维护隐患：后续如果抽象类修改performValidations的方法签名，这个空实现的类也得跟着调整，哪怕它根本不需要这个方法
• 语义模糊：空实现会让其他开发者困惑——这个方法是故意留空，还是遗漏了必要实现？

合理改进方案 #

有两种更符合设计原则的处理方式：

1. 拆分抽象类，严格遵循ISP
   • 将需要验证的逻辑拆分出来，创建一个包含performValidations的抽象子类，让需要验证的具体类继承它；不需要验证的具体类直接继承移除了performValidations方法的原抽象类。这样每个类都只依赖自己真正需要的方法。
2. 用钩子方法实现可选步骤
   • 在抽象类中给performValidations提供默认空实现（而非定义成抽象方法），同时增加一个钩子方法（比如isValidationRequired）来控制是否执行该步骤。示例代码：

     abstract class BaseTask {
         public final void createTask() {
             // 前置共享逻辑
             if (isValidationRequired()) {
                 performValidations();
             }
             // 后续共享逻辑
             doSpecificCreateLogic();
         }
     
         // 钩子方法，默认开启验证
         protected boolean isValidationRequired() {
             return true;
         }
     
         // 提供默认空实现
         protected void performValidations() {}
     
         // 必须实现的具体逻辑
         protected abstract void doSpecificCreateLogic();
     }
     
     class NoValidationTask extends BaseTask {
         @Override
         protected boolean isValidationRequired() {
             return false;
         }
     
         @Override
         protected void doSpecificCreateLogic() {
             // 该类的具体创建逻辑
         }
     }
     

   这种方式既保留了模板方法共享逻辑的优势，又避免了强制实现不需要的方法，同时更符合开闭原则。

内容的提问来源于stack exchange，提问作者Jose Robles Villares