scala - mixins 能解决脆弱的基类问题吗？

Question

在关于编程语言的类(class)中，我的教授引用 mixins 作为脆弱基类问题的解决方案之一。 Wikipedia 也曾经列出 (Ruby) mixins 作为脆弱基类问题的解决方案，但前段时间 someone removed对 mixins 的引用。我仍然怀疑它们在脆弱的基类问题上可能比继承具有某种优势。否则，为什么教授会说他们有帮助？

我将举一个可能的问题的例子。这是教授给我们用来说明问题的(Java)问题的简单 Scala 实现。

考虑以下基类。假设这是列表的一些非常有效的特殊实现，并且在其上定义了更多操作。

class MyList[T] {
    private var list : List[T] = List.empty
    def add(el:T) = {
        list = el::list
    }
    def addAll(toAdd:List[T]) : Unit = {
        if (!toAdd.isEmpty) {
            add(toAdd.head)
            addAll(toAdd.tail)
        }
    }
}

还要考虑以下特征，它应该添加 size到上面的列表。

trait CountingSet[T] extends MyList[T] {
    private var count : Int = 0;
    override def add(el:T) = {
        count = count + 1
        super.add(el)
    }
    override def addAll(toAdd:List[T]) = {
        count = count + toAdd.size;
        super.addAll(toAdd);
    }
    def size : Int = { count }
}

问题是 trait 是否有效取决于我们如何实现 addAll在基类中，即基类提供的功能是“脆弱的”，就像常规 extends 的情况一样在 Java 或任何其他编程语言中。

例如，如果我们使用 MyList 运行以下代码和 CountingSet如上定义，我们返回 5 , 而我们期望得到 2 .

object Main {
    def main(args:Array[String]) : Unit = {
        val myCountingSet = new MyList[Int] with CountingSet[Int]
        myCountingSet.addAll(List(1,2))
        println(myCountingSet.size) // Prints 5
    }
}

如果我们更改 addAll在基类 (!) 中，特征 CountingSet按预期工作。

class MyList[T] {
    private var list : List[T] = List.empty
    def add(el:T) = {
        list = el::list
    }
    def addAll(toAdd:List[T]) : Unit = {
        var t = toAdd;
        while(!t.isEmpty) {
            list = t.head::list
            t = t.tail
        }
    }
}

请记住，我不是 Scala 专家!

Answer 1

Mixins(无论是作为特征还是其他)不能完全防止脆弱的基类综合症，也不能严格使用接口(interface)。原因应该很清楚:您可以对基类的工作进行任何假设，也可以对接口(interface)进行假设。它之所以有帮助，只是因为它会停止并让您思考，并且如果您的界面变得太大，则会施加样板惩罚，这两者都会将您限制在需要的和有效的操作上。

特质真正让你摆脱困境的地方是你已经预料到可能会出现问题的地方；然后你可以参数化你的特质来做适当的事情，或者混合你需要的特质来做适当的事情。例如，在 Scala 集合库中，特征 IndexedSeqOptimized不仅用于指示，而且还用于以在索引与访问集合元素的任何其他方式一样快时表现良好的方式执行各种操作。 ArrayBuffer ，它包装了一个数组，因此具有非常快速的索引访问(事实上，索引是进入数组的唯一方法!)继承自 IndexedSeqOptimized .相比之下，Vector可以相当快地被索引，但是在没有显式索引的情况下进行遍历会更快，所以它不会。如果 IndexedSeqOptimzed不是一个特质，你会很不走运，因为ArrayBuffer处于可变层次结构和 Vector是在不可变的层次结构中，所以不能创建一个通用的抽象父类(super class)(至少在不把其他继承的功能弄得一团糟的情况下)。

因此，您脆弱的基类问题没有得到解决；如果你改变，比如说，Traversable的算法实现，使其具有 O(n)性能而不是 O(1) (也许是为了节省空间)，你显然不知道某个 child 是否会重复使用它并生成 O(n^2)可能是灾难性的表现。但如果你知道，它会使修复变得更容易:只需混合具有 O(1) 的正确特征即可。实现(并且 child 可以在必要时自由地这样做)。它有助于将关注点分解为概念上连贯的单元。

所以，总而言之，你可以让任何东西变得脆弱。特质是一种工具，明智地使用它可以帮助你变得强壮，但它们不会保护你免受任何愚蠢的影响。