我记得在某处看到过有关此问题的辩论，目前正在考虑删除我正在处理的系统中的每个业务对象都继承自的基础对象。它包含一些属性、一些数据库逻辑和一些构造函数逻辑。
这是一个反模式，还是陪审团还在外面？有一个基础契约来继承会更好吗，这需要在每个对象中完成一定数量的样板代码？
编辑：我确实喜欢 dsimcha，并且觉得它很好地反映了这个问题，我仍然很高兴听到任何进一步的答案
【问题讨论】：
标签： anti-patterns oop
标准的经验法则是仅使用继承来通过多态性为类的用户提供灵活性，如果您想重用来自其他类的代码，则使用组合。但是，只要您不违反Liskov Substitution Principle，它可能还不错。编写大量样板代码本质上也是一件坏事，因为它会掩盖代码中发生实际操作的部分并且是反 DRY 的。但是，如果您违反了 Liskov 替换原则，那么这绝对是个坏主意。
【讨论】：
我也想了解我可能会遇到什么问题，或者应该注意什么
如果您使用多重继承，一个潜在的问题是：您的子类会继承“Eve”类的两个实例......这就是 C++ 支持所谓的虚拟继承的原因。
这是一个常用的习惯用法：例如在 .Net 中，所有内容都派生自 System.Object ... 和/或所有 COM 对象都实现 IQueryInterface 接口。
【讨论】：
没有什么是真空中的反模式。你的“夏娃课”给你带来麻烦了吗？您希望从删除它中获得什么好处？询问它是否在 some standard list of anti-patterns 上仅有助于识别实际问题。
【讨论】：