Most applications are layered but share the same domain model (the times where people translate state into layer-specific representations are hopefully gone). Sharing the same domain model classes between different layers is convenient and effective. However if you do that, your domain model tends to become a so called anemic domain model, that is you do not add the behavior to your classes but hold it externally in order to keep the domain model layer independent. This ensures that your domain model only contains code which belongs to the domain and not to a technical layer. That's ok because you do not want to have UI-specific or database-specific code in your domain model if you pass it through all layers.
The problem is that you cannot leverage Java's polymorphism anymore. As a result you either write lengthy if-else cascades in order to dispatch between different types or you use the visitor pattern, which is some kind of external polymorphism support. Well actually the old visitor pattern is not that much external but very invasive. You have to prepare your domain model to be able to accept visitors. That's not always possible and also a lot of work.
Other languages support features to solve this problem. One is pattern matching as known from functional languages which also has made its way to object oriented languages. It's nice and powerful but not available in Java. :-(
Another feature is "multiple dispatch". Languages supporting multiple dispatch (aka "multimethod") decide which method to invoke based on the actual runtime type of the passed arguments. Java in contrast links the method at compile time based on the static types.
This is why in Java the following would print "Hello Fruit":
print((Fruit) new Banana());If Java would support multiple dispatch it would print "Hello Banana", because at runtime the passed argument is an instance of Banana.
static void print(Fruit f) {
sysout("Hello Fruit");
}
static void print(Banana b) {
sysout("Hello Banana");
}
In Xtext we have "added" multiple dispatch to Java (we call it polymorphic dispatch). For instance a label provider is implemented like this:
The framework just calls ILabelProvider.getText(Object element) and the implementation of this method dispatches to the best matching label(Object) method. So if you are interested how it works, have a look at the PolymorphicDispatcher class. Other examples where we use this technique are validation, scoping, qualified name provider, content assist, outline view, etc.
public class MyLabelProvider extends AbstractDeclarativeLabelProvider {
String text(Banana b) {
return "yellow fruit";
}
String text(Apple b) {
return "keeps the doctor away";
}
}
This stuff is very useful for defining such kinds of APIs because it allows us to define nice defaults while the user can add specific behavior just by adding the corresponding methods.
But what if you are in the middle of some implementation and only need to make some decisions based on the type? Write code like this?
Fruit fruit = new Banana();
String result=null;
if (fruit instanceof Banana) {
Banana b = (Banana) fruit;
result = // do stuff with b;
} else if (fruit instanceof Apple) {
Apple a = (Apple) fruit;
result = // do stuff with a;
} else if (fruit instanceof Peach) {
Peach p = (Peach) fruit;
result = // do stuff with p;
}
System.out.println(result);
You might get into trouble with these guys.
How about this one?:
System.out.println(
new Match() {
String is(Banana b) {
return // do stuff with b;
}
String is(Apple a) {
return // do stuff with a;
}
String is(Peach p) {
return // do stuff with p;
}
}.apply(new Banana()));
It's only a bit shorter, but I like it much better because it is functional and more declarative. That is I don't have to declare variables and do side-effects within the different if statements. Also this works for multiple parameters as well.
P.S.: If your domain model is implemented in EMF you get a so called Switch-class generated, which acts similar. So if you only dispatch within that hierarchy and you only need one argument, this works great as well.
