how to find type of object

  • Thread starter Thread starter buller
  • Start date Start date
B

buller

Hi ,,, maybe newbie question maybe not,,, I have not found any solutions yet

private class figur { }
private class square : figur { }
private class rectangle : square { }



List<figur> list = new List<figur>();

list.add ( new square() );
list.add ( new rectangle() );

I want to loop the list and find the square object ...
but if I use "is" like this

if (list is square ) I also get the rectangle since it derived from
square.

How to do ?

Best regards
Kim
 
Hi ,,, maybe newbie question maybe not,,, I have not found any solutions yet

private class figur { }
private class square : figur { }
private class rectangle : square { }

List<figur> list = new List<figur>();

list.add ( new square() );
list.add ( new rectangle() );

I want to loop the list and find the square object ...
but if I use "is" like this

if (list is square  )     I also get the rectangle since it derived from
square.

How to do ?

Best regards
Kim
Click to expand...


A rectangle is not a square so I think you're inheritance hierarchy is
incorrect (at least if you're wanting to adhere to the euclidean
geometry nomenclature). Perhaps if you derive square from rectangle
that would solve your problem.
 
[...]
I want to loop the list and find the square object ...
but if I use "is" like this

if (list is square ) I also get the rectangle since it derived
from
square.

How to do ?
Click to expand...


Instead of using "is", just use the GetType() method and compare to
"typeof(square)".

I'm assuming that the classes you've given are just examples for the
purpose of the question. As Brian, the type hieararchy doesn't really
make much sense.

Pete
 
Hello Peter and Brian

thanks for your time to both of you .

Yes it was just an example , maybe not really thought through .

but without risking to start a longer discussion :)
this site are intersting in the matter if a rectangle can derive from
square .. since a rectangle contains more info than a square

http://www.themacaque.com/?p=146


And thanks for the answer .. just what I needed.

Best regards
Kim

Peter Duniho said:
[...]
I want to loop the list and find the square object ...
but if I use "is" like this

if (list is square ) I also get the rectangle since it derived
from
square.

How to do ?
Click to expand...


Instead of using "is", just use the GetType() method and compare to
"typeof(square)".

I'm assuming that the classes you've given are just examples for the
purpose of the question. As Brian, the type hieararchy doesn't really
make much sense.

Pete
Click to expand...
 
A rectangle is not a square so I think you're inheritance hierarchy is
incorrect (at least if you're wanting to adhere to the euclidean
geometry nomenclature).
Click to expand...

I agree, but I'm pragmatic and I think you should model your system based on
what's important. In the classic conundrum, in an animal hierarchy, would a
platypus be a mammal or bird or what? Without getting into multiple
inheritance, the answer should be based on which attributes are important to
model in your system.

In his case, there could be come optimizations that he could exploit if he
designed it that way, and only certain properties or computations were
important. Maybe rectangles are rare and squares are common, or vice versa,
or maybe the perimeter or area are more important and have special
calculations.

I'm just sayin', we shouldn't jump to conclusions :-)
 
buller said:
Hello Peter and Brian

thanks for your time to both of you .

Yes it was just an example , maybe not really thought through .

but without risking to start a longer discussion :)
this site are intersting in the matter if a rectangle can derive from
square .. since a rectangle contains more info than a square

http://www.themacaque.com/?p=146
Click to expand...

That's a very good example of what I was talking about - it gives a specific
example. But of course that author is "wrong" too. It is not necessarily
true that rectangles should always be designed as squares.

But in general the author is right in saying "You are using [whatever] ideas
in OO, which make you make the wrong assumption"

The point is to avoid making bad assumptions, and pay attention to what's
important in your system model.
 
Hello Peter and Brian

thanks for your time to both of you .

Yes it was just an example , maybe not really  thought through .

but without risking  to start a longer discussion :)
this site are intersting in the matter if a rectangle can derive  from
square .. since a rectangle contains more info than a square

http://www.themacaque.com/?p=146

And thanks for the answer .. just what I needed.

Best regards
Kim
Click to expand...

Oh, this is going to cause a debate for sure!

I don't agree with the blog. On a theorectical basis the point about
the Liskov Substitution Principal is just plain wrong. Having a
rectangle derive from a square violates the principal because squares
cannot be substituted for rectangles. Your program will fail when it
applies squares-only geometric rules against rectangles.

This is the same fundamental problem that may be forcing you to rely
on alternative mechanisms for type discovery. If your hierarchy
really did adhere to the LSP then the "is" operator would be
sufficient.
 
I don't agree with the blog. On a theorectical basis the point about
the Liskov Substitution Principal is just plain wrong. Having a
rectangle derive from a square violates the principal because squares
cannot be substituted for rectangles. Your program will fail when it
applies squares-only geometric rules against rectangles.
Click to expand...

I don't necessarily agree with all of the blog either, but I don't see the
problem with LSP. He just isn't giving enough information to see any
problem there. I think it's pretty easy to imagine some implementations of
square and rectangle where LSP would work fine with rectangle being
subsitutable for square. Of course if you have something like a single Side
property on a square and a Perimeter property that is calculated as 4 *
Side, then it's not substitutable. But if you have an array of 4 sides on a
square and a calculation that adds these 4, then it is. Who knows why you'd
implement this way, but I'm sure we could imagine many reasons different
implementations might be used based on the goals and priorities. Point
being, it all depends on what you're trying to model and your
implementation.

I don't see anything in the OP's code that would automatically preclude a
rectangle from being substitutable for a square - there's no implementation
to restrict anything. I think the only problem the OP is having is that he
wasn't really sure what "is" means. That's simply a C# language issue. He
simply wanted to use "type == Square" instead of "is".
 
I don't agree with the blog.
Click to expand...

I should also add that I don't agree with the part of the blog that
presupposes that a square must "hide" information from the superclass, if
square inherited from rectangle. That idea is interesting and useful as a
guide in general, but there is no technical reason a square needs to hide
any information. It could easily have a length and width (as long as there
were no strange restriction or computation that required the values for them
to be different.)
 
buller said:
Hello Peter and Brian

thanks for your time to both of you .

Yes it was just an example , maybe not really thought through .

but without risking to start a longer discussion :)
this site are intersting in the matter if a rectangle can derive from
square .. since a rectangle contains more info than a square

http://www.themacaque.com/?p=146


And thanks for the answer .. just what I needed.

Best regards
Kim

Peter Duniho said:
[...]
I want to loop the list and find the square object ...
but if I use "is" like this

if (list is square ) I also get the rectangle since it derived
from
square.

How to do ?
Click to expand...

Instead of using "is", just use the GetType() method and compare to
"typeof(square)".

I'm assuming that the classes you've given are just examples for the
purpose of the question. As Brian, the type hieararchy doesn't really
make much sense.

Pete
Click to expand...
Click to expand...


You all are wrong regarding Square and Rectangle sub classing.
Rectangle, Square and Trapezoid all inherit from abstract Quadrilateral,
which of course inherits abstract Polygon.

:) :) :)
 
Hi All

Thanks to you all .

What a great community :)

My example was from pure fantasy , it was not my actually case only for
describe my problem.
But all your discussion really led me to think , so once again , thx alot to
you all .

proxy user says:
The point is to avoid making bad assumptions, and pay attention to what's
important in your system model.
Click to expand...

I believe this must a major thing.

Best Regards
Kim Pedersen



Family Tree Mike said:
buller said:
Hello Peter and Brian

thanks for your time to both of you .

Yes it was just an example , maybe not really thought through .

but without risking to start a longer discussion :)
this site are intersting in the matter if a rectangle can derive from
square .. since a rectangle contains more info than a square

http://www.themacaque.com/?p=146


And thanks for the answer .. just what I needed.

Best regards
Kim

Peter Duniho said:
[...]
I want to loop the list and find the square object ...
but if I use "is" like this

if (list is square ) I also get the rectangle since it derived
from
square.

How to do ?
Instead of using "is", just use the GetType() method and compare to
"typeof(square)".

I'm assuming that the classes you've given are just examples for the
purpose of the question. As Brian, the type hieararchy doesn't really
make much sense.

Pete
Click to expand...
Click to expand...


You all are wrong regarding Square and Rectangle sub classing. Rectangle,
Square and Trapezoid all inherit from abstract Quadrilateral, which of
course inherits abstract Polygon.

:) :) :)
Click to expand...
 
I don't necessarily agree with all of the blog either, but I don't see the
problem with LSP.  He just isn't giving enough information to see any
problem there.  I think it's pretty easy to imagine some implementations of
square and rectangle where LSP would work fine with rectangle being
subsitutable for square.  Of course if you have something like a singleSide
property on a square and a Perimeter property that is calculated as  4 *
Side, then it's not substitutable.  But if you have an array of 4 sideson a
square and a calculation that adds these 4, then it is.  Who knows why you'd
implement this way, but I'm sure we could imagine many reasons different
implementations might be used based on the goals and priorities.  Point
being, it all depends on what you're trying to model and your
implementation.
Click to expand...

You're forgetting about semantic substitutability. Sure, the code
satisfies the interface substitutability part of it (the compiler
enforces that), but you simply cannot logically masquarade any
rectangle around as if it were a square. Just think about all the
chaos this could cause.
I don't see anything in the OP's code that would automatically preclude a
rectangle from being substitutable for a square - there's no implementation
to restrict anything.  
Click to expand...

Again, the compiler will enforce the interface part of LSP, but it
cannot enforce the semantic part.
I think the only problem the OP is having is that he
wasn't really sure what "is" means.  That's simply a C# language issue. He
simply wanted to use "type == Square" instead of "is".
Click to expand...

Let me ask you this...why does the "is" operator give an undesirable
result in the example?
 
You all are wrong regarding Square and Rectangle sub classing.
Rectangle, Square and Trapezoid all inherit from abstract Quadrilateral,
which of course inherits abstract Polygon.

:) :) :)
Click to expand...

There always has to be a joker in the bunch :)
 
You're forgetting about semantic substitutability. Sure, the code
satisfies the interface substitutability part of it (the compiler
enforces that), but you simply cannot logically masquarade any
rectangle around as if it were a square. Just think about all the
chaos this could cause.
Click to expand...

I'm arguing that you can, depending on what parts of them are important to
you to model, and how it's implemented.
Let me ask you this...why does the "is" operator give an undesirable
result in the example?
Click to expand...

Because the OP thought "is" meant "==".
 
I'm arguing that you can, depending on what parts of them are important to
you to model, and how it's implemented.
Click to expand...

Okay, how would you implement the following method...

public double GetPerimeter(Square a)
{
// What goes here?
}

....given the following inheritance hierarchy.

public class Square
{
public double x { get; set; }
}

public class Rectangle : Square
{
public double y { get; set; }
}
Because the OP thought "is" meant "==".
Click to expand...

So why use inheritance instead of aggregation to begin with?
 
Okay, how would you implement the following method...

public double GetPerimeter(Square a)
{
// What goes here?
}
Click to expand...

I've already shown these in previous examples Brian. Either
a) perimeters aren't important with respect to how you want to use these
obects, or
b)
return a.Side[0] + a.Side[1] + a.Side[2] + a.Side[3]
...given the following inheritance hierarchy.

public class Square
{
public double x { get; set; }
}

public class Rectangle : Square
{
public double y { get; set; }
}
Click to expand...

You obviously wouldn't use a design like that if you were going to inherit
Rectangle from Square, use 1 variable to represent a side, and calculate
perimeter. You've stacked the deck to answer the question the way you want.
Think outside the box and consider other designs/uses.
So why use inheritance instead of aggregation to begin with?
Click to expand...

Ask the OP. Presumably so he could substitute rectangles for squares, I
don't know. It's certainly easy enough for me to come up with a design that
works either way. If you're designing a system that uses vehicles, do you
inherit a bicycle from PassengerVehicle, or from ManualPoweredVehicle, or
from Vehicle, or from VehicleThatCanStayUprightWithoutMoving? I don't know,
it depends on what you're trying to model and which attributes are
priorities to you. If perimeters aren't important to you, then who cares
about how you store variables to calculate them?

The guy who wrote the article linked to had a point - things that have more
information in them tend to go lower in the hierarchy.
 
I've already shown these in previous examples Brian.  Either
a) perimeters aren't important with respect to how you want to use these
obects, or
Click to expand...

Would anything relating to the "squareness" of the object be
important? If so then the given class hierarchy will fail to produce
the desired result for any operation that takes advantage of the
unique "squareness" of the object. If not then why have a Square
object to begin with.
b)
return a.Side[0] + a.Side[1] + a.Side[2] + a.Side[3]
Click to expand...

In the example the Square class only contains a single scalar value to
represent its dimensions.
You obviously wouldn't use a design like that if you were going to inherit
Rectangle from Square, use 1 variable to represent a side, and calculate
perimeter.  You've stacked the deck to answer the question the way you want.
Think outside the box and consider other designs/uses.
Click to expand...

That was the example in the blog. I crafted the question to prove
that Square objects cannot be substituted for Rectangle objects.
Ask the OP.  Presumably so he could substitute rectangles for squares, I
don't know.  
Click to expand...

Well if that were the case then the OP would have derived square from
rectangle instead of the other way around.
It's certainly easy enough for me to come up with a design that
works either way.  If you're designing a system that uses vehicles, do you
inherit a bicycle from PassengerVehicle, or from ManualPoweredVehicle, or
from Vehicle, or from VehicleThatCanStayUprightWithoutMoving?  I don't know,
it depends on what you're trying to model and which attributes are
priorities to you.  If perimeters aren't important to you, then who cares
about how you store variables to calculate them?
Click to expand...

In regards to the vehicle analogy I could derive BicycleVehicle from a
lot of different valid superclasses. But, I certainly wouldn't derive
it from UnicycleVehicle which is what the blogger would have me do
since a bicycle contains an additional wheel's worth of information.
Why? Because a bicycle is not a unicycle nor can a unicycle be
substituted for a bicycle.
The guy who wrote the article linked to had a point - things that have more
information in them tend to go lower in the hierarchy.
Click to expand...

Yep, and more importantly, that would be the blogger's focus when
designing the class hierarchy which I completely disagree with. The
focus should be on whether the subclass logically represents an "is-a"
relationship with the superclass. That way whatever operation you
conceive that can be applied to the superclass can also be correctly
applied to the subclass. That is, the superclass can be substituted
for the subclass. If you adhere to that OO principal then the "is"
operator will be sufficient in most cases.
 
Brian Gideon said:
I've already shown these in previous examples Brian. Either
a) perimeters aren't important with respect to how you want to use these
obects, or
Click to expand...

Would anything relating to the "squareness" of the object be
important? If so then the given class hierarchy will fail to produce
the desired result for any operation that takes advantage of the
unique "squareness" of the object. If not then why have a Square
object to begin with.
b)
return a.Side[0] + a.Side[1] + a.Side[2] + a.Side[3]
Click to expand...

In the example the Square class only contains a single scalar value to
represent its dimensions.
You obviously wouldn't use a design like that if you were going to
inherit
Rectangle from Square, use 1 variable to represent a side, and calculate
perimeter. You've stacked the deck to answer the question the way you
want.
Think outside the box and consider other designs/uses.
Click to expand...

That was the example in the blog. I crafted the question to prove
that Square objects cannot be substituted for Rectangle objects.
Click to expand...

Correct. A square is not an extension of a rectangle, it is a constraint on
a rectangle, so making Square derived from Rectangle is bad. Not all
rectangles are squares, so making Rectangle derived from Square is very bad.

The correct solution is probably to make them siblings inheriting from a
common ancestor (which is probably an interface, not a base class) that
exposes the common operations such as get_Perimeter, get_Diagonal, get_Area,
get_Width, get_Height.

But the example based on get_Perimeter is bad because it simply needs to be
a virtual method.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4299 (20090802) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
proxyuser said:
I should also add that I don't agree with the part of the blog that
presupposes that a square must "hide" information from the superclass, if
square inherited from rectangle. That idea is interesting and useful as a
guide in general, but there is no technical reason a square needs to hide
any information. It could easily have a length and width (as long as
there were no strange restriction or computation that required the values
for them to be different.)
Click to expand...

It's not the information / queryable properties that are the problem. It's
the operations / settable properties.

Rectangle r = new Rectangle();
r.setDimensions(6, 4); // makes good sense
r = new Square();
r.setDimensions(6, 4); // fail

LSP violation.



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4299 (20090802) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
Brian Gideon said:
Okay, how would you implement the following method...

public double GetPerimeter(Square a)
{
// What goes here?
}
Click to expand...

return a.ComputePerimeter(); // :)

For that matter, try to implement

public static double GetArea(Rectangle r)

for any rectangle according to the definition from Euclidean geometry, using
the format widely used throughout Win32:

class Rectangle
{
int Left, Top, Right, Bottom;
}

Can't be done, in general you can only set an upper bound. Only when the
Rectangle type stops meaning "rectangle" and starts meaning "rectangle
aligned to a Cartesian grid" is there a unique result. Of course, that's
how Win32 uses it, but nothing in the documentation ever quite comes out and
says that the type isn't equivalent to rectangles in geometry.

My father always tries to insist that terms used in computing need to have
the same meaning as they do outside. I don't find that realistic or
particularly useful, but documentation should try to be clear on the
difference.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4299 (20090802) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
Back
Top