首页 文章

Mixins vs scala中的成分

提问于
浏览
74

在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 1part 2(顺便说一句,在我看来,大多数其他问题与scala无关或不那么严重 .

你有更多这样的提示吗?

2 回答

  • 39

    如果你只将抽象特征混合到你的类定义中,然后在对象实例化时混合相应的具体特征,那么Scala中可以避免混合的很多问题 . 例如

    trait Locking{
       // abstract locking trait, many possible definitions
       protected def lock(body: =>A):A
    }
    
    class MyService{
       this:Locking =>
    }
    
    //For this time, we'll use a java.util.concurrent lock
    val myService:MyService = new MyService with JDK15Locking
    

    这个结构有几个值得推荐的东西 . 首先,由于需要不同的特质功能组合,它可以防止类别爆炸 . 其次,它允许简单的测试,因为可以创建和混合“无所事事”的具体特征,类似于模拟对象 . 最后,我们完全隐藏了所使用的锁定特性,甚至是锁定特性,来自我们服务的消费者 .

    由于我们已经超越了大多数声称混合的缺点,我们仍然需要在混合和组合之间进行权衡 . 对于我自己,我通常根据假设的委托对象是否完全由包含对象封装,或者它是否可能被共享并具有自己的生命周期来做出决定 . 锁定提供了完全封装的委托的一个很好的例子 . 如果您的类使用锁定对象来管理对其内部状态的并发访问,则该锁定完全由包含对象控制,并且它及其操作都不会作为类的公共接口的一部分进行通告 . 对于像这样的完全封装的功能,我使用mix-ins . 对于共享的内容,如数据源,请使用合成 .

  • 10

    你没有提到的其他差异:

    • 特质类没有任何独立存在:

    Programming Scala

    如果您发现特定特征最常用作其他类的父级,以便子类表现为父特征,则考虑将特征定义为类,以使此逻辑关系更清晰 . (我们说行为是,而不是a,因为前者是继承的更精确的定义,基于Liskov替换原则 - 例如见[Martin2003] . )

    [Martin2003]:Robert C. Martin,敏捷软件开发:原理,模式和实践,Prentice-Hall,2003

    • mixins( trait )没有构造函数参数 .

    因此advice, still from Programming Scala

    避免使用无法初始化为合适默认值的特征中的具体字段 . 改为使用抽象字段或将特征转换为带有的字符构造函数 . 当然,无状态特征在初始化时没有任何问题 . 良好的面向对象设计的一般原则是,实例应始终处于已知的有效状态,从构造过程完成的那一刻开始 .

    最后一部分,关于对象的 initial state ,经常帮助决定给定概念的类(和类组合)和特征(和mixin) .

相关问题