OO设计的一般规则是,您应该建模 - 使用继承的关系,并使用包含/聚合和转发/委派来建立关系.通过GoF的警告,你应该通常倾向于遏制继承,这可能会进一步缩小,或许可以说,如果你能在某一特定情况下对任何一个人提出强有力的理由,那么由于维护,这种遏制通常应得到点头.问题继承有时会导致.
我理解这种想法背后的原因,我并不一定反对.但是,当我看到一个包含大量方法的类时,每个方法只转发到一些实例变量,我看到了一种代码重复的形式.在我看来,代码重复是最终的代码味道.重新实现一个庞大的方法协议只是因为两个类之间的关系并不严格 - 似乎有点矫枉过正.这是添加到系统中的额外的,不必要的代码,现在需要像系统的任何其他部分一样进行测试和记录的代码 - 如果您刚刚继承,则可能不需要编写的代码.
坚持这种遏制继承原则的成本是否超过其收益？
Ada*_*son 19
几乎所有东西的成本都可以超过它的好处.坚持不懈,没有例外规则总会让你陷入困境.通常,使用(如果您的语言/运行时支持它)反射是一个坏主意,以便获得对您的代码不可见的变量的访问.这是一种不好的做法吗？和一切一样,
it depends.
组合有时比直接继承更灵活或更容易维护吗？当然.这就是它存在的原因.同样,与纯组合体系结构相比,继承可以更灵活或更易于维护.然后你有接口或(取决于语言)多重继承.
这些概念都不是坏事,人们应该意识到这样一个事实,即有时我们自己缺乏理解或对变革的抵制会导致我们制造任意规则,将某些东西定义为"坏"而没有任何真正的理由这样做.