为何POODR书中建议将默认值封装为方法而非直接在initialize中设置

这种写法的核心优势是完全贴合面向对象设计的「低耦合、易扩展」原则，比参数默认值写法更适合长期维护的面向对象代码，具体好处可以分为以下几点： #

• 对继承极其友好，避免子类重写初始化逻辑的冗余和风险
  把默认值抽成独立的default_*实例方法后，子类只需要重写对应的默认方法就能修改默认值，完全不需要触碰父类的initialize逻辑，也不用感知父类初始化方法的参数列表变化。
  举个子类扩展的例子：

  class MountainBike < Bicycle
    # 仅重写需要调整的默认值，其余逻辑完全复用父类
    def default_tire_size
      "2.5"
    end
  end
  

  如果用参数默认值的写法，子类要调整默认值就必须重写整个初始化方法的参数列表，还要手动调用super传参，一旦父类后续新增了默认参数，子类没同步修改就会出现bug，耦合度极高。

• 支持复杂动态默认逻辑，代码可读性更高
  默认值如果不是固定字面量，而是需要结合业务逻辑计算（比如根据车型、地区返回不同默认值），写在独立的方法里逻辑清晰、可测试。如果把复杂逻辑塞到initialize的参数默认值里，会让参数列表变得冗长混乱，可读性极差。
  同时Ruby的参数默认值是类定义时求值的，如果默认值是动态对象（比如Time.now、Array.new），写在参数里只会求值一次，所有实例共享同一个对象，完全不符合预期；写在实例方法里就会每次实例化时重新求值，符合直觉。

• 默认值可复用，避免重复代码
  抽出来的default_*方法可以被类内部的其他方法调用，比如重置实例到出厂配置、导出默认配置清单等场景，不需要反复抄写默认值字面量，修改默认值时只需要改一个地方，不会出现多份代码不一致的问题。

• 符合单一职责原则，隔离变化
  initialize的核心职责是接收外部参数、完成实例初始化，不应该承载默认值规则的业务逻辑。把默认值拆分到独立方法后，两类逻辑的变化互不影响：修改默认规则不需要动初始化流程，调整初始化逻辑也不会碰默认值配置，代码边界清晰，后期维护成本更低。

补充小细节：POODR后续也提到了用opts.fetch(:chain, default_chain)代替opts[:chain] || default_chain的优化，可以避免传入false、nil这类合法值时被默认值覆盖的问题，和默认值抽方法的设计是互补的。

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