Class A requires additional info when using it. How to pass it to B?

Question

Note: I am aware of the poor wording of the title but I was unable to come up with a better one. If anyone has a better idea, then please edit the title.

I'm trying to recreate a card game but kind of struggling with a problem. Every card in the game has a color (enum) and rank (enum). Some of the cards have some special abilities which require additional data. These cards always have a special color only given to cards with special abilities. The Game has a stack to which played cards are added through a method void playCard(Card).

An example special ability is changing the color of the card on the top of the stack. The new color is totally up to the player to decide. The problem is that this new color needs to be decided when the card is played and before that the special card's color is just SPECIAL. But how do I pass the new color data in a nice way (i.e. so I don't need to use instanceof and extract the data but just get it as card.getColor())? Ideally I'd like it to be a special card before and after playing it to disguise as a normal card (or make it seem like to). If possible I'd still want to be able to retrieve the original, special card.

I thought about solving this by creating a FakeCard and adding a method to SpecialCard to generate the FakeCard and pass the required data to that method but I'm afraid of additional coupling that would occur as different special cards require different additional data and don't want to violate Open/Closed principle (using this approach would require me to). I can't think of anything else though. Do you have any suggestions as to how approach this problem?

Answer 1

I'm no java developer, but a long-time Magic The Gathering player, so I understand the fact that some games can have cards that do many and crazy different things.

Did you think about changing the way you represent the relations beween the game, its card stack and the cards? Currently I think you have a game that has a deck of cards and a stack of cards. And you have in the class Game a playCard method that plays a Card, because you think the Game or (a player) plays a card.

But instead of the Game playing the cards, think of the cards changing the game. What if you have a Card base class that your cards implement, and you have a Card::play method that takes a GameState and its card stack as an argument? This way each card has the freedom to manipulate and change the game state. Your cards can add themselves to the stack, and decide their own effects. If the card is not special, it will just be played normally.

Now the color the user wants to give to the special card has to be passed somewhere, so you'd need to subclass Card with SpecialCard so that you can pass that additional argument. You would add the SpecialCard::play(GameState game, Color color) method (which would be unittest-friendly because of the dependency injection).

You would then be able to either call Card::play(GameState game) which would call SpecialCard::play(GameState game) where you would ask the user the color he/she wants to use or you could call in your tests.

For a special card, once the user input being retrieved, SpecialCard::play(GameState game) would call SpecialCard::play(GameState game, Color color) with the right information.

Sharing the same internals avoids code duplication and is good for testing too.

Answer 2

If the special ability can be "anything" and may require arbitrary input from the player when it is played, then each kind of SpecialCard actually needs to have its own UI code to get that input from the player. So give SpecialCard an invokeAbility() method which is called by playCard() and either have subclasses of SpecialCard (or give it a field SpecialAbility) to implement the different abilities.

Answer 3

It seems like a problem that can be solved using polymorphism/inheritance. I haven't done Java in a bit and my syntax probably isn't valid but I think I can get my point across. I'm not sure what is preventing you from doing the following

// All classes that implement ICard is guaranteed to have the following private fields and public methods.
interface ICard {
   private Color color;
   private Rank rank;

   public Color getColor();
   public Rank getRank();
   public void invokeAbility();
}

public class Card implements ICard {
   public Card(Color color){
      this.color = color;
   }
   // ... implement getColor and getRank and invokeAbility
}

// SpecialCard is an instance of Card so it can be used in the same manner as Card
public class SpecialCard extends Card {

   // overload the constructor
   public SpecialCard(){

     // Special card instantiated w/o Color enum is defaulted to Color.SPECIAL
     super(Color.SPECIAL);
   }

   public SpecialCard(Color color){

     super(color);
   }

   // Override invokeAbility
   public invokeAbility(){
     // ....
   }
}

Answer 4

With what I understand from the question I would create a ColorChangingCard' class that extends the baseCard` with some the methods that make it special. These methods call methods on the parent class to change the state of the card.

Answer 5

This is rough and the details of whether you want to have a SPECIAL color or not can be changed but it should give you the basic idea:

public interface Card
{
    public enum Color {
        YELLOW, RED, GREEN, BLUE, SPECIAL
    }

    boolean canPlaceOn(Card other);

    Color color();

    default Color playedColor()
    {
        return color();
    }

    Rank rank();

    public void assign(Player player);

    Player player();
}

public class BasicCard extends AbstractCard
{
    private final Rank rank;
    private final Color color;

    BasicCard(Rank rank, Color color)
    {
        this.rank = rank;
        this.color = color;
    }

    @Override
    public boolean canPlaceOn(Card other)
    {
        return other.color() == this.color() || this.rank() == other.rank();
    }

    @Override
    public Color color()
    {
        return color;
    }

    @Override
    public Rank rank()
    {
        return rank;
    }
}

public class SpecialCard extends AbstractCard
{
    private Color color = Color.SPECIAL;

    @Override
    public boolean canPlaceOn(Card other)
    {
        // modify as needed
        return true;
    }

    @Override
    public Color Color()
    {
       return Color.SPECIAL;
    }

    @Override
    public Color playedColor()
    {
       while (color == Color.SPECIAL) {
           color = UserInterface.selectColor(player());
       }

       return color;
    }

    @Override
    public Rank rank()
    {
        // not sure what goes here
        return null;
    }
}

Answer 6

 > Class A requires additional info when using it. How to pass it to B?

Your original question was: how to tell the PlayEngine "B" that Card "A" is something special?

If you follow the tell, don-t ask pattern you learn that player "X" tells specialCard "A" which color to use and specialCard "A" tells PlayEngine "B" which color to use.

You need two different types of card:

• most cards are of type "Card where color cannot be changed"
• and there are a few "Card where the player can tell the card which color it should have at runtime"

Both card types have a method play() that tells the PlayEngine which color is next

If your StandardCard also has a setColor() method (which i do not recomment) then it-s implementation should throw a PlayerIsCheetingException :-) )

Answer 7

Try a visitor with 2 methods with the same name, but one taking RegularCard as a parameter and one with SpecialCard.

Then you can define a method in BaseCard which will take visitor and invoke with itself resolving the subtype.

Something like this:

class CardDealer {
    void play(RegularCard card) {
        ...
    }
    void play(SpecialCard specialCard) {
        ...
    }
}
abstract class Card {
    draw(CardDealer visitor) {
        visitor.play(this);
    }
}

or

interface Playable {
    void play(CardDealer dealer);
}

and overwrite method accordingly, in this case you can use different names for visitor methods

Answer 8

Your problem in modeling comes from your getColor() being dual-use:

1. Determining whether you can play the card, meaning following suit. bool canPlay(Suit) would be more appropriate.
2. Determining which suit has to be followed by the next card. Suit getSuit() would be appropriate.

So, you need two functions, one returning its played color, Suit getSuit(), and one determining whether it can be played canPlay(Suit).

Special Cards additionally need a function to change the color, setSuit().

Depending on how you decide to play it, you need at least two classes, RegularCard and SpecialCard. Either they implement / inherit from a common interface / base, or the latter extends the former. Both solutions are valid.

Answer 9

The card doesn't change color. The color named when the card is played is part of the game state, along with, for example, the turn direction (if you implement a "reverse" card).

You might find it easier to implement the game in a test-driven fashion, instead of trying to come up with an initial class design. The input to each test would be the game state and a possible card to play, and the output would be whether it is legal to play that card and the resulting game state. Then you can test and implement one rule at a time. Factor out classes as it becomes convenient.