newbie: GetType or typeof?

[deko]

I have a method I need to pass an object reference to like this:

private void updateSchedule(object obj)
{
if (obj is ThisObj)
{
myVar1 = obj.PropertyA
myVar2 = objPropertytB
}
else if (obj is ThatObj)
{
myVar3 = obj.Property1
myVar4 = obj.Property2
}
else if (obj is OtherObj)
{
myVar5 = obj.PropertyI
myVar6 = objPropertyII
}
}

The properties of the different objects are not related in any way.

What is the best way to test for object type? GetType? typeof? examples?

Thanks in advance.

 

[Jon Skeet [C# MVP]]

I have a method I need to pass an object reference to like this:

The properties of the different objects are not related in any way.

What is the best way to test for object type? GetType? typeof? examples?

Using "is" is fine. Is there no way that the different types could
implement a common interface, to avoid all this? This kind of code
*usually* indicates that the design could be improved.

Jon

 

[deko]

Using "is" is fine. Is there no way that the different types could

implement a common interface, to avoid all this?

Well, I could have one obj inherit from the other.

So if I pass a base and a derived object to the same method, how do I access
the properties of one from the other?

This kind of code
*usually* indicates that the design could be improved.

no doubt about that...

 

[Jon Skeet [C# MVP]]

Well, I could have one obj inherit from the other.

No, that's not what I was suggesting. Inheritance for the sake of it is
a bad idea. See
http://msmvps.com/blogs/jon.skeet/archive/2006/03/04/inheritancetax.aspx

However, if the types all implement the same *interface* then you could
make that interface the type of the parameter. If all the properties
you need are in that interface, you can just let polymorphism do the
work.

Jon

 

[deko]

No, that's not what I was suggesting. Inheritance for the sake of it is

a bad idea. See
http://msmvps.com/blogs/jon.skeet/archive/2006/03/04/inheritancetax.aspx

However, if the types all implement the same *interface* then you could
make that interface the type of the parameter. If all the properties
you need are in that interface, you can just let polymorphism do the
work.

I've heard it said that "inheritance is the coolest feature you'll never
use".

But for the sake of argument, let's say the cfg object did in fact inherit
from the prj object, and the method in question looked like this:

private void updateSchedule(ProjectObject prj)
{
myVar1 = prj.PropertyA
myVar2 = prj.PropertytB
myVar3 = prj.PropertyC
myVar4 = prj.PropertyD
}

So I am trying to send a ConfigurationObject cfg to this method.
Configurations inherit from Projects, but Configurations do not (at least as
the class is now written) have all the same properties as a Project. So,
how do I get this to work? Do I include the base class properties in the
derived class definition (copy and paste the property code from Project to
Configuration) and then add this to the Configuration constructor:

this.projectID = base.ProjectID;
etc...

Is there a better way?

As things turn out, inheritance is a good idea with these two objects - it's
not just for the sake of it. But I did read your blog and you make some
good points.

 

[Jon Skeet [C# MVP]]

I've heard it said that "inheritance is the coolest feature you'll never
use".

But for the sake of argument, let's say the cfg object did in fact inherit
from the prj object, and the method in question looked like this:

private void updateSchedule(ProjectObject prj)
{
myVar1 = prj.PropertyA
myVar2 = prj.PropertytB
myVar3 = prj.PropertyC
myVar4 = prj.PropertyD
}

So I am trying to send a ConfigurationObject cfg to this method.
Configurations inherit from Projects, but Configurations do not (at least as
the class is now written) have all the same properties as a Project. So,
how do I get this to work?

Rather than making UpdateSchedule do the work *on* the different types,
in many cases it would be better to make the interface contain another
UpdateSchedule method, so that each ConfigurationObject knows how to
update its own schedule. It can use whatever properties it needs.
Basically, it's a case of pushing more knowledge to the specific types,
rather than having one type which knows what to do with lots of
different ones.
Whether or not this works in your particular situation is hard to know,
but that's often a good way of working.

Jon

 

[deko]

Rather than making UpdateSchedule do the work *on* the different types,

in many cases it would be better to make the interface contain another
UpdateSchedule method, so that each ConfigurationObject knows how to
update its own schedule. It can use whatever properties it needs.
Basically, it's a case of pushing more knowledge to the specific types,
rather than having one type which knows what to do with lots of
different ones.
Whether or not this works in your particular situation is hard to know,
but that's often a good way of working.

But can I overload the method? Because both would take one object and have
the same return type, I don't think I can.

 

[Nick Hounsome]

I have a method I need to pass an object reference to like this:

private void updateSchedule(object obj)
{
if (obj is ThisObj)
{
myVar1 = obj.PropertyA
myVar2 = objPropertytB
}

This will not compile because PropertyA is not a property of Object.

if( obj is ThisObj )
{
ThisObj thisObj = (ThisObj)obj;
myVar1 = thisObj.ProprtyA;
myVar2 = thisObj.ProprtyB;
}

 

[Kenneth Siewers Møller]

I have a method I need to pass an object reference to like this:

private void updateSchedule(object obj)
{
if (obj is ThisObj)
{
myVar1 = obj.PropertyA
myVar2 = objPropertytB
}
else if (obj is ThatObj)
{
myVar3 = obj.Property1
myVar4 = obj.Property2
}
else if (obj is OtherObj)
{
myVar5 = obj.PropertyI
myVar6 = objPropertyII
}
}

The properties of the different objects are not related in any way.

What is the best way to test for object type? GetType? typeof?
examples?

Thanks in advance.

Perhaps if you define an interface ISchedule with two properties called
PropertyA and PropertyB. Then you could implement the interface in all the
objects and test what it is using polymorphism.

private void updateSchedule(ISchedule sch){
ISchedule o = sch as ISchedule;;
if(sch is ThisObj){ // ThisObj implements ISchedule
myVar1 = o.PropertyA;
myVar2 = o.PropertyB;
}
else if(sch is ThatObj){ // ThatObj implements ISchedule
myVar3 = o.PropertyA;
myVar4 = o.PropertyB;
}
else if(sch is OtherObj){ // OtherObj implements ISchedule
myVar5 = o.PropertyA;
myVar6 = o.PropertyB;
}
}

I guess that would work...

 

[deko]

Perhaps if you define an interface ISchedule with two properties called

PropertyA and PropertyB. Then you could implement the interface in all the
objects and test what it is using polymorphism.

private void updateSchedule(ISchedule sch){
ISchedule o = sch as ISchedule;;
if(sch is ThisObj){ // ThisObj implements ISchedule
myVar1 = o.PropertyA;
myVar2 = o.PropertyB;
}
else if(sch is ThatObj){ // ThatObj implements ISchedule
myVar3 = o.PropertyA;
myVar4 = o.PropertyB;
}
else if(sch is OtherObj){ // OtherObj implements ISchedule
myVar5 = o.PropertyA;
myVar6 = o.PropertyB;
}
}

An interface sounds like a good idea. But all classes that update the
schedule would have to provide implementation to do so. Getting that done
seems to be the first order of business, then I can implement the
interface.... ?

 

[Jon Skeet [C# MVP]]

But can I overload the method? Because both would take one object and have
the same return type, I don't think I can.

No, you can't overload by return type (unless you're using C# 2.0 and
use generics cunningly) but you could just declare your method to
return object. The method you showed returned void though, so I'm not
sure I see where the problem is.