Inhertance Question

[Simon]

Hi folks,

Take the following scenario:

public class BaseType {


}

public class DerivedTypeA : BaseType {

int _length;

public int Length {
get { return _length; } set { _length = value; }
}
}

public class DerivedTypeB : BaseType {

int _lowBound;
int _highBound;

public int LowBound {
get { return _lowBound; } set { _lowBound = value; }
}
}

public class BaseTypeCollection : BindingList<BaseType> {

}

An instance of the collection will contain various instances of the two
derived types and in the future many more derived types. At various
times I need to iterate through each item setting various values.

I can see a problem in that I still need to test within an iteration
routine the actual type of each instance, which to me sort of defeats
the reason for deriving from a base class in the first place.

Comments welcome.

Cheers

Simon

 

[Vadym Stetsyak]

Do you want to iterate over elements of specified type?

you can use smth like Dictionary<BaseType, BindingList<BaseType>>
then you will ask dictionary to return elements of specific type

 

[Simon]

I suppose what I'm getting at is:

Take my previous example but now add a method called Render() which each
subtype implements. This is great because I can call Render on any
BaseType derived instance but before I set or get data into any instance
I need to check what derivation it implements to make sure I am calling
a getter or setter that actualy exists.

This makes me think I am going to have big decision structures that will
need to be maintained every time I add a new derived type.

I know this isn't correct and I am missing something in the design.

I had the thought of adding virtual properties to the base type which do
nothing and then overriding when they are relevant.

For example, to flesh out my example.

public class BaseType {

public virtual Length {
get { return -1; } set { }
}

public virtual LowBound {
get { return -1; } set { }
}

public virtual HighBound {
get { return -1; } set { }
}

}

public class DerivedTypeA : BaseType {

int _length;

public override int Length {
get { return _length; } set { _length = value; }
}
}

public class DerivedTypeB : BaseType {

int _lowBound;
int _highBound;

public override int LowBound {
get { return _lowBound; } set { _lowBound = value; }
}

public override int HighBound {
get { return _highBound; } set { _highBound = value; }
}

public class BaseTypeCollection : BindingList<BaseType> {

}

This just seems wrong to me. It doesn't feel elegant.

Simon

 

[Kevin Spencer]

Hi Simon,

I can see a problem in that I still need to test within an iteration
routine the actual type of each instance, which to me sort of defeats the
reason for deriving from a base class in the first place.

There are many reasons to use inheritance, but your example is not an
example of one of them. A good example would be something like
System.Windows.Forms.Form, which is the base class for all forms. It
contains all the code necessary to create a container for Form UI controls.
To create a form, you simply inherit System.Windows.Forms.Form, and add the
Controls and logic to the new class that you need to create your
application.

By using a base class that has all the code needed to create a variety of
derived classes, redundancy is avoided, and maintenance of the common code
is done through just one implementation.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Joanna Carter [TeamB]]

"Simon" <[email protected]> a écrit dans le message de (e-mail address removed)...

| An instance of the collection will contain various instances of the two
| derived types and in the future many more derived types. At various
| times I need to iterate through each item setting various values.
|
| I can see a problem in that I still need to test within an iteration
| routine the actual type of each instance, which to me sort of defeats
| the reason for deriving from a base class in the first place.

You need to look at the Visitor design pattern. It is intended to add
functionality to a hierarchy of classes without altering the code of the
clesses themselves. It also allows you to execute different code, depending
on the type of the item being visited.

public interface IVisitor
{
}

public interface IVisitable
{
void Accept(IVisitor visitor);
}

public class MyHierarchyVisitor : IVisitor
{
public MyHierarchyVisitor(...)
{
// pass parameters to internal fields for external objects that will be
used
// whilst visiting nodes in a list.
}

void VisitDerivedTypeA(DerivedTypeA node)
{
// do something specific to a DerivedTypeA object
}

void VisitDerivedTypeB(DerivedTypeB node)
{
// do something specific to a DerivedTypeB object
}
}

public abstract class BaseType : IVisitable
{
...

public abstract void Accept(IVisitor visitor);
}

public class DerivedTypeA : BaseType
{
...

public override void Accept(IVisitor visitor)
{
if (visitor is MyHierarchyVisitor)
((MyHierarchyVisitor) visitor).VisitDerivedTypeA(this);
}
}

public class DerivedTypeB : BaseType
{
...

public override void Accept(IVisitor visitor)
{
if (visitor is MyHierarchyVisitor)
((MyHierarchyVisitor) visitor).VisitDerivedTypeB(this);
}
}

Then you treat your list like this :

{
List<BaseType> items...

// add items to list

MyHierarchyVisitor visitor = new MyHierarchyVisitor(...);

foreach (IVisitable node in items)
node.Accept(visitor as IVisitor);
}

Joanna

 

[Simon]

Ah nice one Joanna,

Gang of Four book open and I'm reading

Thanks again

Simon