Abstracts: can I do better than this?

[Paulo Zemek]

Why can't you do something like: SelectedDevice.Set(this) Which Set being virtual (abstract), so the right one is called without the IF and also, if newer classes appear, you don't need to change the "Deciding" code.

[Lost User]

MollyTheCoder wrote:

I have a base class, Device, and a bunch of derived classes Dev1, Dev2

SetDevice((Device)SelectedDevice);

This one?

I are Troll :suss:

[PIEBALDconsult]

Is the casting required at all? Even if SetDevice is overloaded for each type there shouldn't be a problem should there? And if not, then you still don't need to cast to each type. Edit: I just tried it and I see the problem. More information about SetDevice would be helpful. And, as Luc said, use is rather than comparing types. Edit: Or perhaps SetDevice should handle determining which type of device it was passed:

private static void
SetDev
(
DevBase Dev
)
{
System.Console.WriteLine ( "DevBase" ) ;

if ( Dev is Dev1 ) SetDev ( (Dev1) Dev ) ;
else if ( Dev is Dev2 ) SetDev ( (Dev2) Dev ) ;

return ;

}

modified on Wednesday, December 30, 2009 2:01 PM

[MollyTheCoder]

I have a form with device information for for each type of device. Most of the information is similar, so I'm sharing a single form, using SetDevice() to setup fields and controls specific to each derived device type. (right now, all SetDevice methods are inside the form, not the Device classes). SelectedDevice is instantiated as a Device, then cast to whichever derived class is appropriate. The cast is necessary because at compile-time, SelectedDevice is just a Device, but at run-time will have a specific derived type.

[PIEBALDconsult]

I wonder whether or not dynamics in C# 4 will do it.

[MollyTheCoder]

PIEBALDconsult wrote:

Or perhaps SetDevice should handle determining which type of device it was passed.

Wouldn't that mean creating a big SetDevice to handle all types, and just move the same code into SetDevice? Even if the code is a little less ugly thanks to is. Molly

[pbalaga]

Afaik, the 'is' keyword is not fully equal to x.GetType() == typeof(y) . Let's say I have: class A class B:A (B inheriting from A) Then following (pseudo-)code:

b = new B();
b is A

returns true and

b = new B();
b.GetType() == typeof(A)

returns false. The latter option checks for an exact type match.

[Lost User]

Paul89 wrote:

b = new B();
b.GetType() == typeof(A);

The above test the immediate types A.GetType() != B.GetType() && B.GetType() != A.GetType() for a better understanding try this:

b = new B();
a = new A();

typeof(A).ToString();
typeof(B).toString();

a.GetType().toString();
b.GetType().toString();

However this works like the is keyword: B.IsSubclassOf(A) returns true -or- A.IsAssignableFrom(B) returns true On the is key word: 'An is expression evaluates to true if the provided expression is non-null, and the provided object can be cast to the provided type without causing an exception to be thrown.'

modified on Wednesday, December 30, 2009 2:42 PM

[MollyTheCoder]

Thanks! I think is works for the code I've got today, but you probably saved me from myself on some future project. Molly

[petercrab]

looks fine to me.

[PIEBALDconsult]

Or maybe not! :laugh:

[MollyTheCoder]

Who goes 400 pages deep (as of today) into a forum just to rub it in? :sigh:

[PIEBALDconsult]

That'd be me. :-D But I took a shortcut -- I saw on your profile that you had only posted a few questions, I checked those few. I didn't actually know I'd find this.