面向对象编程(OOP)中仅部分子类用到的函数声明在父类是否是不良实践？

两种写法的问题分析 #

写法2（加减方法放到父类A）属于不良实践 #

float A::AddNumbers(){...}
float A::SubtractNumbers(){...}

该写法违反接口隔离原则：父类定义的方法应该是所有子类通用的能力，Ac、Ad完全不需要加减能力，却被迫继承了两个无关方法，既会造成接口污染，也会提高误用概率，比如其他开发者误调用Ac实例的AddNumbers方法。如果Ac、Ad为了兼容父类接口给这两个方法写空实现/抛异常，还会违反里氏替换原则，导致父类引用指向子类实例时出现不可预期的错误。

写法1（Aa、Ab各自实现加减方法）存在冗余问题 #

float Aa::AddNumbers(){...}
float Aa::SubtractNumbers(){...} 

float Ab::AddNumbers(){...}
float Ab::SubtractNumbers(){...} 

该写法虽然解决了接口污染的问题，但两份几乎一致的代码会带来额外维护成本，后续修改加减逻辑需要同步修改两处，很容易出现漏改导致的一致性问题。

最优实现方案 #

新增中间抽象层即可同时解决两个问题：

• 顶层父类A仅保留4个子类都需要用到的通用函数
• 新增继承自A的中间类A_ArithmeticBase，在该类中实现AddNumbers和SubtractNumbers方法，可通过构造参数/虚函数钩子处理Aa、Ab的参数差异
• Aa、Ab继承自A_ArithmeticBase，Ac、Ad直接继承自A

如果加减属于可选扩展能力，也可以用接口实现：定义纯虚的算术能力接口，Aa、Ab多继承该接口实现对应方法，不会影响原有A的继承链结构。

特殊场景的优先级权衡 #

如果受限于现有项目架构约束，暂时无法新增中间层，优先选择写法1：接口污染的危害远高于少量代码冗余的影响，尤其是项目迭代周期长、参与开发人员多的场景下，父类的冗余方法会带来很多隐性维护成本。只有当加减方法逻辑极其简单、后续几乎没有迭代修改可能，且所有开发人员都明确知道Ac、Ad不应该调用这两个方法的极端场景下，才可以考虑写法2，且必须在方法注释中明确标注仅Aa、Ab可用。

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