Replace Conditional with Polymorphism - How to handle when your type changes?

Question

For a personal project, I'm working on a small web-based game.

I have a Card class that has a Status property, and there are case statements all over the place. I thought, hey, this is a great oppurtunity for Replace Conditional with Polymorphism!

The problem is, I have a couple methods that do stuff like this:

public class Card
{
    public void ChangeStatus()
    {
      switch (Status)
      {
        case MyStatusEnum.Normal:
          Status = MyStatusEnum.Underwater;
          break;
        case MyStatusEnum.Underwater:
          Status = MyStatusEnum.Dead;
          break;
        // etc...
      }
    }
}

When refactoring it in the new NormalCard class, I'm overriding the ChangeStatus method like this:

public override void ChangeStatus()
{
    base.Status = MyStatusEnum.Underwater;
}

The problem is this object of NormalCard has a status of Underwater. I can't reassign the type of this, and I don't really want to change the return of the methods from void to CardBase. What options do I have? Is there a standard way of doing this?

Edit Tormod set me straight. I want the State Pattern. Thanks all!

@Inerdial - Yeah, I see what you mean, and if it was just this one statement, I would leave it. It's the fact that there's these `cases` all over the place that makes me think this is a candidate for refactoring. — Matt Grande, Feb 28 '12 at 15:40
@Tormod - If I'm reading about the State Pattern correctly, my `Card` object would have a `StateContext` (or something) property, and there would be, for example, `UnderwaterState` that inherits from `StateContext` and knows how to perform the various actions? — Matt Grande, Feb 28 '12 at 15:45
@MattGrande Sorry for the confusion, the comment I deleted was based on me reading your question wrong. — millimoose, Feb 28 '12 at 16:06
@MattGrande Yes. That is correct. You will have one part of the Card object which changes (its "currentState" object) to which you delegate all state influenced decisions. You swap out the object whenever you change state. Like a Strategy, but expected to change during the lifetime of the host object (the context), and often capable of replacing itself (making the context transition to a new state). — Tormod, Feb 28 '12 at 18:43

millimoose · Accepted Answer · 2012-02-28T15:55:59.057

In your case, I'd have a Card object that contains a CardStatus property. The subtypes of CardStatus correspond to the previous enum values. Refactor behaviour that depends on the current status except the state transition to be inside the CardStatus subtypes.

The state transition that's in your first example should, IMO, remain inside the Card object. The state changing feels more like a behaviour of the containing card than of the state object. What you can do is have the CardStatus objects tell you what state to transition to after an event.

A rough example: (obviously there's many more variations on this that could be used.)

API

interface ICardStatus {
    ICardStatus NextStatus(Card card);

    void DoStuff(Card card);
}

class Card {
    ICardStatus Status = new NormalCardStatus();

    void DoStuff() {
        Status.DoStuff(this);
    }

    void ChangeStatus() {
        Status = Status.NextStatus(this);
    }
}

Status implementations

class NormalCardStatus : ICardStatus {
    ICardStatus NextStatus(Card card) {
        return new UnderwaterCardStatus();
    }

    void DoStuff(Card card) {
        // ...
    }
}

class UnderwaterCardStatus : ICardStatus {
    ICardStatus NextStatus(Card card) {
        return new DeathStatus();
    }

    void DoStuff(Card card) {
        // ...
    }
}

class DeathCardStatus : ICardStatus {
    ICardStatus NextStatus(Card card) {
        // ...
    }

    void DoStuff(Card card) {
        throw new Exception("Cannot do anything while dead");
    }
}

score 2 · Answer 2 · answered Feb 28 '12 at 15:47

You could write the Status class with polymorphism:

class Status
{
    Status GetNextStatusWhenFooHappens() {}
    Status GetNextStatusWhenBarHappens() {}
    Status GetNextStatusWhenBloopHappens() {}
}

Each method returns the status to move to, or anything else you're doing in a case right now. And then you can override these methods for each specific status. The Card class will not be polymorphic with this implementation, but it will hold a polymorphic Status member.

score 1 · Answer 3 · answered Feb 28 '12 at 15:40

1

Replacing a conditional with polymorphism is useful in some cases, but it's not clear that it's appropriate here... at least not with straight enums. You could introduce a "smart enum" type instead of MyStatusEnum, where each value knew about the "next" value - then you wouldn't necessarily be using polymorphism, but you would be using a fixed set of values with more information than a standard enum.

Another alternative is to have a simple Dictionary<MyStatusEnum, MyStatusEnum> going from "current status" to "next status". It really depends on whether there's more that you need to do. I suspect we're not really going to be able to offer very good advice based just on the code you've presented.

answered Feb 28 '12 at 15:40

Jon Skeet

1,421,763
867
9,128
9,194

It's not just this one method. There are several occurances of case statements where different actions take place. – Matt Grande Feb 28 '12 at 15:43
1

@MattGrande: Different actions, or just different sets of transitions? This is what I mean in my last paragraph - when we only know a small part of the story, we can't really help very much. Does the behaviour always depend solely on the state? Would it make sense for the state itself to have behaviour? – Jon Skeet Feb 28 '12 at 15:44

Replace Conditional with Polymorphism - How to handle when your type changes?

3 Answers3

API

Status implementations

Linked