父类调用子类方法为何被认为是错误的？

第一种实现的核心问题 #

第一种写法看似简洁，但违背了面向对象设计的多个核心原则，主要问题有：

• 依赖倒置原则被打破：正常的面向对象设计应该是子类依赖父类的抽象，而这里父类直接依赖子类的具体方法generate_more_results，导致父类的正常运行完全绑定在子类的实现上，逻辑依赖关系完全反转。
• 隐式耦合带来维护灾难：父类调用子类方法的逻辑是“暗箱操作”，新开发者如果不深入查看父类代码，根本不知道子类的generate_more_results会被自动调用。一旦子类修改方法名、参数或者忘记实现，父类的generate_results会直接报错，而且这种错误往往要到运行时才会暴露，排查难度大。
• 缺乏强制约束：父类没有明确要求子类必须实现generate_more_results，如果新增子类时开发者遗漏了这个方法，程序会直接抛出致命错误，没有任何提前预警。
• 职责边界模糊：父类本来只该处理所有子类共享的通用初始化逻辑，现在却直接介入子类的业务逻辑调用，把通用逻辑和特化逻辑混在了一起，违反了单一职责原则。

问题的严重程度 #

这个问题的危害程度和项目规模正相关：

• 小型项目/一次性代码：可能暂时不会出问题，甚至因为代码少觉得高效，但只要代码量一增加，隐式耦合的问题就会凸显出来。
• 中大型团队项目：这种写法会成为协作的绊脚石，子类的任何修改都可能牵连父类，排查问题需要反复追溯调用链，极大降低开发效率。
• 长期维护项目：代码的可读性、可扩展性会越来越差，后续重构需要付出极高的成本，甚至可能因为耦合太深无法重构。

这种写法是否会一直被诟病 #

只要面向对象的设计思想还是主流，这种写法就会被视为不良实践——因为它本质上是对面向对象核心原则的违背。不过也有极端场景可以勉强接受：比如项目非常小、子类数量固定且团队所有人都明确知晓这个隐式调用关系，但即便如此，依然不推荐，因为后续的维护风险远大于一时的简洁。

其实有个折中的优化方案，既能保留第一种写法的简洁，又能规避风险：把父类改成抽象类，明确声明抽象方法强制子类实现：

abstract class Parent_Class {
  public function generate_results() {
     // 所有子类共享的初始化逻辑
     $this->generate_more_results();
  }

  abstract protected function generate_more_results();
}

这样既让父类的依赖关系变得明确，又强制子类必须实现对应的方法，从根源上避免了隐式耦合的问题。

两种写法的本质区别 #

第一种写法的“简洁”是牺牲了代码的可维护性和清晰度换来的，第二种写法虽然多了几行代码，但逻辑更透明：

• 子类完全掌控自己的执行流程，主动调用父类的初始化方法，职责划分一目了然。
• 没有任何隐藏的调用关系，开发者看子类代码就能完整了解整个逻辑流程。
• 父类专注于通用逻辑，不干涉子类的具体实现，完全符合面向对象的设计原则。

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