I agree that this is crying out for an OO based solution.
Another commonly used solution would be to create process objects and
then use a factory method from the original class to return a
processing object. This can often times help reduce duplication of
code while keeping the inheritance chain simple (sometimes simply
putting the process method in forces alot of code duplication)
ex:
public class SomeProcess : IProcess {
public void Something() {
Console.WriteLine("SomeProcess");
}
}
public class SomeOtherProcess : IProcess {
public void Something() {
Console.WriteLine("SomeOtherProcess");
}
}
public class Foo {
public virtual IProcess GetProcess() {
return SomeProcess;
}
}
public class FooDerived : Foo {
public override IProcess GetProcess() {
return new SomeOtherProcess();
}
}
On 7/17/06, John Brett <[EMAIL PROTECTED]> wrote:
<snip>
> My problem is when you have a lot of subclasses to Node that you want to
> process in different ways the second example gets very deeply nested and
> hard to maintain. Is there a better way to deal with multiple downcasts
> like this?
The example above is crying out for an object-oriented solution. Add an
abstract "Process" method to your base class, and lose all of the casts.
If you absolutely can't do that, then you could build an if/elseif tree based
on node.GetType(), although even that's pretty poor practice unless you
absolutely can't use the OO approach.
John
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
--
If knowledge can create problems, it is not through ignorance that we
can solve them.
Isaac Asimov
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
