CODEWITHSUNDEEP
c#refactoringpolymorphism
Matt Grande
Matt Grande

Reputation: 12157

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

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!

Upvotes: 3

Views: 6198

Answers (3)

millimoose
millimoose

Reputation: 39990

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");
    }
}

Upvotes: 3

escargot agile
escargot agile

Reputation: 22389

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.

Upvotes: 2

Jon Skeet
Jon Skeet

Reputation: 1503629

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.

Upvotes: 1

Related Questions