在java世界中(更准确地说,如果你没有多重继承/ mixins),经验法则很简单:“赞成对象组合而不是类继承” .
如果你还考虑mixins,我想知道它是否/如何改变,特别是在scala中?
mixins被认为是多重继承的方式,还是更多的类组合?
是否还有"Favor object composition over class composition"(或其他方式)指南?
当人们使用(或滥用)mixins时,我已经看到了一些例子,当对象组合也可以完成这项工作时,我并不总是确定哪一个更好 . 在我看来,你可以用它们实现非常相似的东西,但也有一些差异,一些例子:
-
可见性 - 使用mixins,一切都成为公共API的一部分,而不是组合的情况 .
-
冗长 - 在大多数情况下,mixins不那么冗长,也更容易使用,但情况并非总是如此(例如,如果你也在复杂的层次结构中使用自我类型)
我知道简短的回答是“它取决于”,但可能有一些典型的情况,当这个或那个更好 .
到目前为止,我可以提出一些指导原则(假设我有两个特征A和B,A想要使用B中的一些方法):
-
如果要使用B中的方法扩展A的API,则使用mixins,否则使用合成 . 但是,如果我创建的类/实例不是公共API的一部分,它就无济于事 .
-
如果你想使用一些需要mixins的模式(例如Stackable Trait Pattern),那么这是一个简单的决定 .
-
如果你有循环依赖,那么mixins与self类型可以提供帮助 . (我尽量避免这种情况,但这并不容易)
-
如果你想要一些动态的,运行时决定如何组合然后对象组合 .
在很多情况下,mixins似乎更容易(和/或更简洁),但我很确定它们也有一些陷阱,比如"God class"和其他两篇artima文章中描述的其他文章:part 1,part 2(顺便说一句,在我看来,大多数其他问题与scala无关或不那么严重 .
你有更多这样的提示吗?
2 回答
如果你只将抽象特征混合到你的类定义中,然后在对象实例化时混合相应的具体特征,那么Scala中可以避免混合的很多问题 . 例如
这个结构有几个值得推荐的东西 . 首先,由于需要不同的特质功能组合,它可以防止类别爆炸 . 其次,它允许简单的测试,因为可以创建和混合“无所事事”的具体特征,类似于模拟对象 . 最后,我们完全隐藏了所使用的锁定特性,甚至是锁定特性,来自我们服务的消费者 .
由于我们已经超越了大多数声称混合的缺点,我们仍然需要在混合和组合之间进行权衡 . 对于我自己,我通常根据假设的委托对象是否完全由包含对象封装,或者它是否可能被共享并具有自己的生命周期来做出决定 . 锁定提供了完全封装的委托的一个很好的例子 . 如果您的类使用锁定对象来管理对其内部状态的并发访问,则该锁定完全由包含对象控制,并且它及其操作都不会作为类的公共接口的一部分进行通告 . 对于像这样的完全封装的功能,我使用mix-ins . 对于共享的内容,如数据源,请使用合成 .
你没有提到的其他差异:
(Programming Scala)
[Martin2003]:Robert C. Martin,敏捷软件开发:原理,模式和实践,Prentice-Hall,2003
trait
)没有构造函数参数 .因此advice, still from Programming Scala:
最后一部分,关于对象的 initial state ,经常帮助决定给定概念的类(和类组合)和特征(和mixin) .