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