I am attempting to model a card game where cards have two important sets of features:
The first is an effect. These are the changes to the game state that happen when you play the card. The interface for effect is as follows:
boolean isPlayable(Player p, GameState gs);
void play(Player p, GameState gs);
And you could consider the card to be playable if and only if you can meet its cost and all its effects are playable. Like so:
// in Card class
boolean isPlayable(Player p, GameState gs) {
if(p.resource < this.cost) return false;
for(Effect e : this.effects) {
if(!e.isPlayable(p,gs)) return false;
}
return true;
}
Okay, so far, pretty simple.
The other set of features on the card are abilities. These abilities are changes to the game state that you can activate at-will. When coming up with the interface for these, I realized they needed a method for determining whether they can be activated or not, and a method for implementing the activation. It ends up being
boolean isActivatable(Player p, GameState gs);
void activate(Player p, GameState gs);
And I realize that with the exception of calling it "activate" instead of "play", Ability and Effect have the exact same signature.
Is it a bad thing to have multiple interfaces with an identical signature? Should I simply use one, and have two sets of the same interface? As so:
Set<Effect> effects;
Set<Effect> abilities;
If so, what refactoring steps should I take down the road if they become non-identical (as more features are released), particularly if they're divergent (i.e. they both gain something the other shouldn't, as opposed to only one gaining and the other being a complete subset)? I'm particularly concerned that combining them will be non-sustainable as soon as something changes.
The fine print:
I recognize this question is spawned by game development, but I feel it's the sort of problem that could just as easily creep up in non-game development, particularly when trying to accommodate the business models of multiple clients in one application as happens with just about every project I've ever done with more than one business influence... Also, the snippets used are Java snippets, but this could just as easily apply to a multitude of object oriented languages.
