A few days ago the second beta of Groovy 2.3 got released. One of the major new Groovy 2.3 features are traits. A trait is a reusable set of methods and fields that can be added to one or more classes. A class can be composed out of multiple traits without using multiple inheritance (and therefore avoiding the diamond problem).
Basic usage of Groovy Traits
The following piece of code shows a basic definition of a trait in Groovy 2.3.
trait SwimmingAbility { def swim() { println "swimming.." } }
A trait definition looks very similar to a class definition. This trait defines a single method swim(). We can add this trait to a class using the implements keyword:
class Goldfish implements SwimmingAbility { .. }
Now we are able to call the swim() methods on Goldfish objects:
def goldfish = new Goldfish() goldfish.swim()
So far we could have accomplished the same using inheritance. The difference is that we can add multiple traits to a single class. So let's define another trait:
trait FlyingAbility { def fly() { println "flying.." } }
We can now create a new class that makes use of both traits:
class Duck implements SwimmingAbility, FlyingAbility { .. }
Ducks can swim and fly now:
def duck = new Duck() duck.swim() duck.fly()
this inside traits
Inside traits the this keyword represents the implementing instance. This means you can write the following:
trait FlyingAbility { def fly() { println "${this.class.name} is flying.." } }
In case of the Duck class from above this will print
Duck is flying..
if we call duck.fly().
A more complex example
Now let's look at an example that shows some more features of Groovy traits
trait Trader { int availableMoney = 0 private int tradesDone = 0 def buy(Item item) { if (item.price <= availableMoney) { availableMoney -= item.price tradesDone += 1 println "${getName()} bought ${item.name}" } } def sell(Item item) { .. } abstract String getName() }
Like Groovy classes traits support properties. Here the property availableMoney will become private and public getter / setter methods will be generated. These methods can be accessed on implementing classes. tradesDone is a private variable that cannot be accessed outside the Trader trait. Within this trait we defined an abstract method getName(). This method has to be implemented by classes that make use of this trait.
Let's create a class that implements our Trader trait:
class Merchant implements Trader { String name String getName() { return this.name } }
A Merchant is now be able to buy items:
def bike = new Item(name: 'big red bike', price: 750) def paul = new Merchant(name: 'paul') paul.availableMoney = 2000 paul.buy(bike) // prints "paul bought big red bike" println paul.availableMoney // 1250
Extending from traits, Overriding and conflict resolution
A trait can inherit functionality from another trait using the extends keyword:
trait Dealer { def getProfit() { ... } def deal() { ... } } trait CarDealer extends Dealer { def deal() { ... } }
Here the CarDealer trait extends Dealer and overrides the deal() method of Dealer.
Trait methods can also be overwritten in implementing classes:
class OnlineCarDealer implements CarDealer { def deal() { ... } }
If a class implements more than one trait it is possible to create a conflict. That's the case if two or more traits define a method with an identical signature:
trait Car { def drive() { ... } } trait Bike { def drive() { ... } } class DrivingThing implements Car, Bike { ... }
In such a situation the last declared trait wins (Bike in this example).
Conclusion
I think traits are a very useful concept and I am happy to see them in Groovy. Other than Groovy mixins traits work at compile time and can therefore be accessed from Java code. For further reading I can recommend the Groovy 2.3 Trait documentation.
Comments
Steve - Friday, 25 April, 2014
"last declared trait wins"... I think this is really the only key difference to remember, when it comes to Java inheritance.
Pluto - Monday, 28 April, 2014
Thank you for the explanation. is clear even if I don' t appreciate how Traits manage conflicts for multiple implementations.
I would have appreciated something similar to Java interface's default method way.
Leave a reply