Best way to switch behavior based on type

Question

Possible Duplicate:
C# - Is there a better alternative than this to ‘switch on type’?

Consider the classic:

class Widget { }
class RedWidget : Widget { }
class BlueWidget : Widget { }

For the most part, in my UI, I can treat all Widgets the same. However, there are minor differences, which I need to if or switch through.

Possible approaches:

Enum Indicator - set by constructor

enum WidgetVariety { Red, Blue }

class Widget {
    public WidgetVariety Variety { get; protected set; }
}

class RedWidget : Widget {
    public RedWidget() {
        Variety = Red;
    }
}

// Likewise for BlueWidget...

switch (mywidget.Variety) {
case WidgetVariety.Red:
    // Red specific GUI stuff

case WidgetVariety.Blue:
    // Blue specific GUI stuff
}

Use is

Widget w = ...;
if (w is RedWidget) {
    (RedWidget)w ...
}
else if (w is BlueWidget) {
    (BlueWidget)w ...
}

The reason I've resorted to this is 1) Most of the code is already somewhat written this way, but much uglier. 2) 90% of the code is identical - basically just one column in a GridView needs to be handled differently depending on the type.

Which would you recommend? (Or anyone have a better solution?)

Edit I know I'll probably be recommended to the Visitor Pattern, but that simply seems to complicated for sparse, minor differences in this case.

Edit 2 So one particular difference I was having a hard time sorting out is this column that is different between the two types. In one case, it retrieves a bool value, and assigns that to the grid cell. In the other case, it gets a string value.

I suppose in this case, it should be obvious that I could define:

public object virtual GetColumn4Data();

public override GetColumn4Data() { return m_boolval; }

public override GetColumn4Data() { return m_mystring; }

This felt wrong to me initially, due to the use of object. However, that is the type of the property that I am assigning to in the cell, so of course this makes sense!

Too long at the office today it seems...

It sounds like what you're saying is: since most of the code is already written poorly, you need to continue the trend by writing more ugly hard-to-maintain code. — M.Babcock, Apr 11 '12 at 22:49
If your subclasses have a type that varies between them, then maybe the base class should be generic. Then it becomes `public virtual T GetColumn4Data(); ... public override bool GetColumn4Data() { return m_boolval; } ... public override string GetColumn4Data() { return m_mystring; }` — Dave Cousineau, Apr 11 '12 at 23:30
@Sahuagin - Please save larger code snippets for answers. Comments don't do them justice. — M.Babcock, Apr 11 '12 at 23:57
see also http://stackoverflow.com/questions/156467/switch-pattern-matching-idea http://stackoverflow.com/questions/7252186/switch-case-on-type-c-sharp http://stackoverflow.com/questions/7542793/how-to-use-switch-case-on-a-type http://stackoverflow.com/questions/4478464/c-sharp-switch-on-type http://stackoverflow.com/questions/298976/c-sharp-is-there-a-better-alternative-than-this-to-switch-on-type — Mikhail Poda, May 01 '12 at 11:57
and http://stackoverflow.com/questions/94305/what-is-quicker-switch-on-string-or-elseif-on-type http://stackoverflow.com/questions/6304815/why-is-this-switch-on-type-case-considered-confusing http://stackoverflow.com/questions/5947343/how-to-switch-between-possible-type-of-an-object http://stackoverflow.com/questions/2551773/c-sharp-which-is-the-best-alternative-to-switch-on-type — Mikhail Poda, May 01 '12 at 11:57

score 9 · Accepted Answer · answered Apr 11 '12 at 22:49

9

There's another possibility. Use virtual dispatch:

class Widget
{
    public virtual void GuiStuff() { }
} 
class RedWidget : Widget
{
    public override void GuiStuff()
    {
        //... red-specific GUI stuff
        base.GuiStuff();
    }
} 
class BlueWidget : Widget
{
    public override void GuiStuff()
    {
        //... blue-specific GUI stuff
        base.GuiStuff();
    }
}

answered Apr 11 '12 at 22:49

phoog

42,068
6
79
117

Of course.... see my Edit 2 :-) – Jonathon Reinhart Apr 11 '12 at 22:57

score 5 · Answer 2 · edited Jun 20 '20 at 09:12

5

Subtype polymorphism is the best solution, avoiding this kind of checks is one of the main reasons OO was created.

Widget might have a method DoSomething() (abstract probably) and then RedWidget and BlueWidget would override it.

Also see Martin Fowler's Replace Conditional with Polymorphism:

Seen: You have a conditional that chooses different behavior depending on the type of an object.

Refactor: Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract.

edited Jun 20 '20 at 09:12

Community

1
1

answered Apr 11 '12 at 22:49

jorgehmv

3,633
3
25
39

2

I disagree with the idea that [this kind of] polymorphism was "why OO was created"; it is more of an *effect* of some "OO languages". However, +1 for the other bits. (There are more kinds of polymorphism than boring -- and dangerous! -- single-dispatch subtypes found in C#/Java, for instance.) – Apr 11 '12 at 23:05
@pst i see your point, interesting topic – jorgehmv Apr 11 '12 at 23:25

score 0 · Answer 3 · answered Apr 12 '12 at 00:42

For your question under Edit #2, you could use a generic class to make the type vary among subclasses, though it may or may not work for you depending on your design. It will probably lead to other tough design decisions.

Rough example:

internal abstract class BaseClass
{
   protected object mValue; // could also be defined as a T in BaseClass<T>

   public object GetColumn4Data { get { return mValue; } }
}

// this is a group of classes with varying type
internal abstract class BaseClass<T> : BaseClass
{
   public T GetTypedColumn4Data 
   {
      get { return (T)mValue; } 
      set { mValue = value; }
   }
}

// these are not really necessary if you don't plan to extend them further
// in that case, you would mark BaseClass<T> sealed instead of abstract
internal sealed class BoolSubClass : BaseClass<bool>
{
   // no override necessary so far
}

internal sealed class StringSubClass : BaseClass<string>
{
   // no override necessary so far
}

Notice, however, that you can't really get a single reference type that will have a varying return type on some property or method. A BaseClass reference will at best return a general type (like object).

Unfortunately that won't work here. This particular type difference is just one of several small, but important differences. Were it the only difference though, I would agree with this approach. — Jonathon Reinhart, Apr 12 '12 at 00:58

Best way to switch behavior based on type

3 Answers3

Linked