I don't know that I agree with the approach but you could do
enum CanDos {
TALK,
WALK,
SLEEP,
SIT,
STARE
}
And then the class could have
abstract class Foo {
abstract Set<CanDos> getCanDos();
//or
abstract boolean can(CanDos item);
}
And you can use an EnumSet
for efficient storage of the capabilities.
If all you are looking for is the Right Thing to provide a set of enums (like the field in the parent abstract class you mention) then I think EnumSet<CanDos>
is your guy. In that case
abstract class Foo {
private final Set<CanDos> candos;
protected Foo(Set<CanDos> candos)
{
this.candos = new EnumSet<CanDos>(candos);
}
public boolean can(CanDos item) {
return candos.contains(item);
}
}
Alternatively you could avoid the abstract class altogether (or at least not mandate it see e.g. this question or this one). The well-regarded book Effective Java suggests "Prefer interfaces to abstract classes".
To do this, instead
enum CanDos {
TALK,
WALK,
SLEEP,
SIT,
STARE
}
public interface FooThatCanDo {
boolean can(CanDos item);
}
If you really think there's value in a common inheritance root (which you should think hard about) then you could provide an abstract base implementation as shown above, and declare that it implements FooThatCanDo
.