I tagged this question both Java and Scala because while I mainly develop on Java I’d like to see if the solution on Scala will be different.
I have a problem with designing classes for my application. I have a set of common objects with different behaviour. As I recently read some book about patterns I told: “Okay, I can use a Strategy pattern here”, define behaviour as some field object and delegate it all the logic. And here are my problem started 🙂
Let’s say I have a base class Duck which can fly and I delegate flying to some FlyBehaviour.
interface IFlyable { void fly(); }
interface IFlyBehaviour { void fly(); }
class Duck implements IFlyable {
IFlyBehaviour flyBehaviour;
void fly() {
flyBehaviour.fly();
}
}
But my ducks are a little different and I realize that I want the behaviour to depend on it. First I have a SpaceDuck which should fly in space and use a spaceShip field which defined only for SpaceDuck. Next I have a HelicopterDuck which I want to fly as low as possible and use some anti-air-defence flares which are defined only for HelicopterDuck. So in code it’s something like this
class SpaceDuck extends Duck {
String spaceship;
}
class SpaceFlyBehaviour implements IFlyBehaviour {
void fly() {
System.out.println("Flying in space on spaceship: " + spaceduck.spaceship);
}
}
class HelicopterDuck extends Duck {
int flares;
}
class HelicopterFlyBehaviour implements IFlyBehaviour {
void fly() {
while(helicopterduck.flares > 0) {
System.out.println("I'm going low and using flares");
helicopterduck.flares--;
}
}
}
Here in my behaviour implementations I don’t actually have a reference to spaceduck or helicopterduck and this code won’t compile. I just provided a sample of how I imagined and would like it to be. I could modify IFlyBehaviour and pass duck as an argument to fly() method but then I have to downcast to get access to duck specific fields which is not a good idea I guess.
It looks like the obvious way is just dropping IFlyBehaviour away and move the logic to fly() method of each duck. But I expect a lot of different space fly behaviours and helicopter behaviours and fly() is not the only method. It will be squack(), run() and etc. and each with different set of behaviours. So my class hierarchy will become huge and unsupportable.
In my real application I will have some runnable and stoppable instances which can be run and stopped in different way. One instance would be started via SSH script, another via MBean (or SSH, it depends on how user configured it), third using some 3rd party and etc. So I hope the Duck sample reflexes my problem quite well.
Any thoughts to push me in right direction would be very helpful. Thanks in advance!
In Scala, traits were included just for this kind of stuff.
In Java, it is more difficult. I would try getting rid of the duck subclasses rather than the behaviours, moving the type-specific properties into the behaviour classes. If you only use the ducks via their common interface, these properties are unavailable anyway – they should only be seen at the point of instantiation.