I agree, they all seem to allow reusing multiple "classes" of behaviour. There are differences, though, and
understanding these will probably aid your decision.
Before providing a brief summary/highlight of each feature and examples of suitable
usage, let's just summarize on the conclusion of each.
Conclusion / typical usage:
- @Delegate: Used to add all the functionality of the delegate class, but still avoid tightly coupling to the
actual implementation. Let's you achieve composition over inheritance.
- @Mixin: Deprecated with groovy 2.3. Simple way to add methods from one or more classes into your class. Bug-ridden.
- Runtime mixin: Add one or more methods into any existing class, e.g. a class in the JDK or a 3rd party library.
- Traits: New in groovy 2.3. Well-defined way to add one or more traits to your class. Replaces @Mixin. The only
one of these where added methods are visible in Java classes.
And now, let's look into each of these with a little bit more detail.
@Delegate
Inheritance is over-used in many cases. That is, it is often improperly used. Classic examples in Java are
extending input streams, readers or the collection classes.. For most of these, using inheritance is too
tightly coupled with the implementation. That is, the actual implementation is written so that one of the
public methods actually use another. If you override both, and you call super, then you might get unwanted
side-effects. If the implementation changes in a later version, then you will have to update your handling of
it as well.
Instead, you should strive to use composition over inheritance.
Example, a counting list that counts the elements added to a list:
class CountingList<E> {
int counter = 0
@Delegate LinkedList<E> list = new LinkedList<>()
boolean addAll(Collection<? extends E> c) {
counter += c.size()
list.addAll(c)
}
boolean addAll(int index, Collection<? extends E> c) {
counter += c.size()
list.addAll(index, c)
}
// more add methods with counter updates
}
In this example, the @Delegate removes all the tedious boiler-plate code for all public methods that you
want to leave "as-is", i.e. methods are added that simply forwards the call to the underlying list. In addition,
the CountingList is separated from the implementation so that you don't have to care whether one of these
methods is implemented by calling the other. In the example above, that is actually the case, since
LinkedList.add(Collection) calls LinkedList.add(int, Collection), so it would not be as straight-forward
to implement using inheritance.
Summary:
- Provides default implementations for all public methods in the delegated object.
- Methods with same signature that are explicitly added, take precedence.
- Implicitly added methods are not visible in Java.
- You can add several
@Delegates to one class.
- but if you do, you should consider whether that is really desirable.
- what about the diamond problem, i.e. if you have multiple methods in the delegates with the same signature?
- The class with delegates (
CountingList in the example above) are not instances of the delegate class.
- I.e.
CountingList is not an instance of LinkedList.
- Use to avoid tightly coupling through inheritance.
@Mixin
The @Mixin transform will be deprecated with groovy 2.3, due to the upcoming traits support. This provides a
hint that everything that is possible to do with @Mixin, should be possible to do with traits instead.
In my experience, @Mixin is sort of a mixed blessing. :)
It is, by the core developers admission, bug-ridden with "hard-to-solve" bugs. That's not to say that it's been
"useless", far from it. But if you have the opportunity to use (or wait for) groovy 2.3, then you should use
traits instead.
What the AST transform does, is simply to add the methods from one class into another. For instance:
class First {
String hello(String name) { "Hello $name!" }
}
@Mixin(First)
class Second {
// more methods
}
assert new Second().hello('Vahid') == 'Hello Vahid!'
Summary:
- Adds methods from one class into another.
- Use in groovy <2.3 for simple addition of methods from one class to another
- don't add to "super" classes (at least, I've had problems with that)
- Bug-ridden
- Deprecated from groovy 2.3
- Implicitly added methods are not visible in Java.
- The class that gets another class mixed in, are not instances of that other class
- I.e.
Second is not an instance of First
- You can mix in several classes into one other class
- what about the diamond problem, i.e. if you have methods in the mixed in classes with the same signature?
- Use as a simple method of adding the functionality of one class into another in groovy <2.3
Runtime mixin
Runtime mixins and the @Mixin transform are quite different, they solve different use-cases and are used
in totally different situations. Since they have the same name, it's easy to confuse one with the other, or to
think that they are one and the same. Runtime mixins, however, are not deprecated in groovy 2.3.
I tend to think about runtime mixins as the way to add methods to existing classes, such as any class in the JDK.
It's the mechanism used by Groovy to add extra methods to the JDK.
Example:
class MyStringExtension {
public static String hello(String self) {
return "Hello $self!"
}
}
String.mixin(MyStringExtension)
assert "Vahid".hello() == 'Hello Vahid!'
Groovy also have a nice extension module feature, where you don't need to manually perform the mixin, instead
groovy does it for you as long as it finds the module descriptor in the correct location in the classpath.
Summary:
- Add methods to any existing class
- any classes in the JDK
- any 3rd party classes
- or any of your own classes
- Overrides any existing method with the same signature
- Added methods are not visible in Java
- Typically used to extend existing/3rd party classes with new functionality
Traits
Traits are new to groovy 2.3.
I tend to view these traits as something between the familiar interface and class. Something akin to a "light-weight"
class. They are dubbed "interfaces with default implementations and state" in the documentation.
Traits are similar to the @Mixin transform that they replace, but they are also more powerful. For starters, they
are much more well-defined. A trait cannot be instantiated directly, just like an interface, they need an implementing
class. And a class may implement many traits.
A simple example:
trait Name {
abstract String name()
String myNameIs() { "My name is ${name()}!" }
}
trait Age {
int age() { 42?}
}
class Person implements Name, Age {
String name() { 'Vahid' }
}
def p = new Person()
assert p.myNameIs() == 'My name is Vahid!'
assert p.age() == 42
assert p instanceof Name
assert p instanceof Age
The immediate difference between traits and @Mixin is that trait is a language keyword, not an AST transform.
Further, it can contain abstract methods that needs to be implemented by the class. Further, a class can implement
several traits. The class implementing a trait is an instance of that trait.
Summary:
- Traits provide an interface with implementation and state.
- A class can implement multiple traits.
- Methods implemented by a trait are visible in Java.
- Compatible with type checking and static compilation.
- Traits can implement interfaces.
- Traits can not be instantiated by themselves.
- A trait can extend another trait.
- Handling of the diamond problem is well-defined.
- Typical usage:
- add similar traits to different classes.
- (as an alternative to AOP)
- compose a new class from several traits.
