Question

In a class on programming languages, my professor quotes mixins as one of the solutions to the fragile base class problem. Wikipedia also used to list (Ruby) mixins as a solution for the fragile base class problem, but some time ago someone removed the reference to mixins. I still suspect that they might somehow have an advantage over inheritance with regards to the fragile base class problem. Otherwise, why would a professor say that they help?

I’ll give an example of a possible problem. This is a simple Scala implementation of the (Java) problem that the professor gave us to illustrate the problem.

Consider the following base class. Assume that this is some very efficient special implementation of a list, and that more operations are defined on it.

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)
        }
    }
}

Also consider the following trait, which is supposed to add size to the list above.

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 }
}

The problem is that whether or not the trait will work depends on how we implement addAll in the base class, i.e. the functionality provided by the base class is ‘fragile’, just as would be the case with a regular extends in Java or any other programming language.

For example, if we run the following code with MyList and CountingSet as defined above, we get back 5, whereas we would expect to get 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
    }
}

If we change addAll in the base class (!) as follows, the trait CountingSet works as expected.

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
        }
    }
}

Keep in mind that I am anything but a Scala expert!

Answer 1

Mixins (whether as traits or something else) cannot completely prevent fragile base class syndrome, nor can strictly using interfaces. The reason should be pretty clear: anything you can assume about your base class’s workings you could also assume about an interface. It helps only because it stops and makes you think, and imposes a boilerplate penalty if your interface gets too large, both of which tend to restrict you to needed and valid operations.

Where traits really get you out of trouble is where you already anticipate that there may be a problem; you can then parameterize your trait to do the appropriate thing, or mix in the trait you need that does the appropriate thing. For example, in the Scala collections library, the trait IndexedSeqOptimized is used to not just indicate but also implement various operations in a way that performs well when indexing is as fast as any other way to access elements of the collection. ArrayBuffer, which wraps an array and therefore has very fast indexed access (indeed, indexing is the only way into an array!) inherits from IndexedSeqOptimized. In contrast, Vector can be indexed reasonably fast, but it’s faster to do a traversal without explicit indexing, so it does not. If IndexedSeqOptimzed was not a trait, you’d be out of luck, because ArrayBuffer is in the mutable hierarchy and Vector is in the immutable hierarchy, so couldn’t make a common abstract superclass (at least not without making a complete mess of other inherited functionality).

Thus, your fragile base class problems are not solved; if you change, say, Traversable‘s implementation of an algorithm so that it has O(n) performance instead of O(1) (perhaps to save space), you obviously can’t know if some child might use that repeatedly and generate O(n^2) performance which might be catastrophic. But if you do know, it makes the fix much easier: just mix in the right trait that has an O(1) implementation (and the child is free to do that whenever it becomes necessary). And it helps divorce concerns into conceptually coherent units.

So, in summary, you can make anything fragile. Traits are a tool that, used wisely, can help you be robust, but they will not protect you from any and all follies.