views:

47

answers:

2

Given these C# classes (generated by WCF, I can't change these):

public SysState GetSysState();

public class SysState { /* nothing much here */}
public class Normal : SysState { /* properties & methods */  }
public class Foobar : SysState { /* different properties & methods */  }

My code (currently):

SysState result = GetSysState();

if (result is Normal) HandleNormal((Normal) result);

if (result is Foobar) HandleFoobar((Foobar) result);

My question: I keep feeling I'm missing something obvious, that I shouldn't need to check type explicitly. Am I having a senior moment?

A: 

You might try combining handleX and placing Handle in SysState and over-riding it in both Normal and Foobar to perform specific tasks. It may not be the perfect solution, but it would look relatively neat. If you need to input data from other sources, pass them as parameters?

public class SysState
{
    public bool Process(Information info)
    {
        return ( info.Good );
    }
}

public class Normal
{
    public bool Process(Information info)
    {
        return doStuff();
    }
}

public class Foobar
{
    public bool Process(Information info)
    {
        return diePainfully();
    }
}

Obviously just an example, not knowing what HandleNormal and HandleFoobar do, but it could work nicely.

peachykeen
I can't change those classes, they're auto-generated. When the WDSL changes, any customizations will be lost. Otherwise yes, that would be fine.
egrunin
Ah. Well, that won't work at all then. Could you cast them to a common type that has a processing function to handle any differences?
peachykeen
Just mark your custom class partial. svcutil already does so with the generated classes. You can put all your custom code in your own class without having to worry about the generated one when the wsdl changes.
Kirk Woll
@Kirk: good point, I'll try that.
egrunin
+1  A: 

Use a virtual method. Put your code in the classes that they operate on, not in some code that gets a reference to the class.

public class SysState {
  /* nothing much here, except...: */
  public abstract virtual void DoSomething();
}

public class Normal : SysState {
  /* properties & methods */
  public override void DoSomething()
  {
    // ...
  }
}

public class Foobar : SysState {
  /* different properties & methods */
  public override void DoSomething()
  {
    // ...
  }
}

SysState result = SomeFunctionThatReturnsObjectDerivedFromSysState();

result.DoSomething();

This will execute the derived class's DoSomething method. This is called polymorphism, and is the most natural (and some would argue the only correct) use of inheritance.

Please note that SysState.DoSomething doesn't have to be abstract for this to work, but it does have to be virtual.

Merlyn Morgan-Graham
+1 I'll try this, thanks.
egrunin
@egrunin: If you absolutely cannot change the classes at all, then you obviously can't do this, and you'll have to resort to using "if this is type ... else if this is other type...". However, you can write your own wrapper classes on the client side to take care of this problem for you. The wrapper classes would have these classes as their guts, and provide a public interface that does polymorphism. You'd still need the "if this type, then...", but you'd only have to write it once, where it converts the types to your wrappers.
Merlyn Morgan-Graham