Usage Patterns of Scala Traits

One of the many cool features in Scala are traits. traits are like a mixture of abstract classes and interfaces: You can ‘implement’ as many of them as you want just as with interfaces, but they can also contain implementation, which makes them similar to abstract classes. You also can’t instantiate a trait on its own, so there is another similarity to abstract classes.

While digging my way through various libraries I found a couple of different usage patterns, how traits are getting used. Here is what I found so far:

The Introvert Trait: These are traits that aren’t intended for changing the behavior of a class for outside clients of the class, but for the code inside the class itself. They often make an internal DSL available. An example are the ShouldMatchers in ScalaTest. You mix in this trait into your test class in order to use syntax like someValueToTest should be (23) The problem with this kind of usage is that you can’t really control the scope in which your trait/DSL applies. So if you want to use two such traits which happen do define the same method or operator with different meaning you are in trouble. Often you can replace the trait with an object which you import. Since scoping rules apply for imports as well you can control much better which part of your class have access to that object. I see two reasons why this kind of trait makes sense: It makes the presence of the trait/DSL very obvious since it is right next in the beginning of the class declaration, while an import statement might get overlooked. The other reason is, if you want to fool around with self types, i.e. you want to limit the kind of classes the trait can get mixed in to or if you want to reference that class.

Classes with dissociative identity disorder: Sometimes things are two things at once. A wooden chair might be furniture as well as fuel for an oven. A square is a rectangle and a rhombus. This works perfectly with traits. While in java you would often have two interface, but one class implementing both, you can easily split the implementation between two traits in scala. Nice. But you should carefully check if these two behaviors  actually belong in a single class, or if you are violating the Single Responsibility Principle.

The Jigsaw Puzzle Trait: In this pattern traits are used to separate different aspects of a responsibility in a very fine grained manner. The results are traits that are really hard to understand on their own. Actually they are easy to understand since the often only consist of half a dozen lines of code. What is difficult is to understand how this can be useful in any way. Yet if done right it allows do reduce code duplication to an absolute minimum. The best example for this usage is the Scala collection API. It consists of a huge number of traits, that get assembled in different ways in order to form the different classes.

The Steam Roller Trait: What happens when you drive a steam roller over something small, let’s say an interface? It gets very wide. This is another technique used in the Scala Collection API. The trait defines a self type, either using another trait or a structural type and defines lots of other stuff based on that interface. This completely solves one of the basic challenges in Java interface design: If you define wide interfaces, i.e. interfaces with lots of methods, it increases the chances for users to find the method they need. On the other hand those poor bastards who have to implement such an interface have a lot of work to do. If you have any doubts how powerful this pattern is, check out how little code you have to write in order to create a new collection implementation which nicely integrates with all the others and has hundreds of methods just like all the other Scala collections as well.

From http://blog.schauderhaft.de/2011/08/21/usage-patterns-of-scala-traits/