模板方法模式中为何通过超类发送消息获取子类特化实现？

这种基类定义通用流程、主动调用子类特化方法的设计，就是模板方法模式的核心，完全不是多此一举，核心是把「不变的通用逻辑」和「可变的特化逻辑」做了彻底拆分，实际开发中的优势非常实在：

• 从根源上消灭子类重复代码
  所有子类共通的逻辑（比如例子里的初始化流程：读取传入参数、无传入值时回退到默认值、属性赋值）全部收敛在基类写一次就行，不需要每个子类重复写一模一样的initialize方法。如果后续要调整通用逻辑，只需要改基类一处，不用挨个修改N个子类，也不会出现漏改的问题。

• 强制统一契约，避免子类漏实现、错实现逻辑
  例子里基类的default_tire_size直接抛出NotImplementedError，本质是明确告诉所有继承的子类：「轮胎默认值是你必须提供的信息」，只要子类忘了实现对应方法，对象初始化时就会直接抛出明确的错误，不会等到业务运行到半路才出现nil、属性缺失这类难排查的隐性bug。
  如果让子类自己实现全量逻辑，很容易出现各种不一致：比如有的子类写死属性值直接忽略用户传入的自定义参数，有的子类漏写某个通用属性的赋值，有的子类默认值回退逻辑写得和其他子类不统一，这类问题在子类数量多了之后几乎必然出现。

• 通用逻辑修改完全收敛，扩展成本极低
  举个实际场景：如果后续要给所有自行车新增「车铃」这个属性，只需要在基类的initialize方法里加一行@bell = opts[:bell] || default_bell，再在基类实现通用的default_bell方法返回标准车铃即可，有特殊车铃需求的子类单独覆写default_bell就行，其余所有代码完全不用动。
  如果是每个子类自己维护初始化逻辑，你需要逐个修改所有子类的initialize方法，不仅工作量大，还很容易出现漏改、错改。

• 遵循好莱坞原则降低耦合
  这种设计完全符合「不要调用我们，我们会调用你」的好莱坞原则：子类根本不需要知道基类的完整执行流程，不需要在重写initialize时刻意记着调用super、不需要关心super需要传什么参数，只需要专注实现自己的特化方法、返回正确的特化值即可，基类会在流程的对应节点主动触发这些方法，子类和基类的耦合度被压到最低。

给个反例你就能直观感受到差距，如果不用这种设计，让子类自己实现全量逻辑，很容易写出这种问题代码：

# 反面实现：子类各自维护逻辑，问题百出
class BadRoadBike < Bicycle
  def initialize(**opts)
    @size = opts[:size]
    # 漏写chain的默认值回退，没传参数时chain为nil
    @chain = opts[:chain]
    # 直接写死tire_size，完全忽略用户传入的自定义轮胎尺寸
    @tire_size = "23"
  end
end

class BadMountainBike < Bicycle
  def initialize(**opts)
    # 漏了size属性赋值
    @chain = opts[:chain] || "11-speed"
    @tire_size = opts[:tire_size] || "2.1"
  end
end

这类零散的错误在项目规模起来之后会变成维护噩梦，而模板方法模式从设计层面就把这些出错的可能性堵死了。

内容的提问来源于stack exchange，提问作者hitzoglin