Polymorphism & Collections

[Jerad Rose]

I'm relatively new to C# and polymorphism, so what I'm trying to accomplish
may not be possible, or there may be a totally different approach that I
should be taking.

I have a base class (MyBase) and a collection of MyBase objects
(MyBaseCollecti on). Now, I also have an extension to MyBase (MyExtendedBase
: MyBase) that has additional properties. And lastly, I have a collection
of MyExtendedBase objects(MyExten dedBaseCollecti on : MyBaseCollectio n).

I have a data layer that has a method (GetMyBaseColle ction) that retrieves
records from the database, and populates a MyBaseCollectio n with these
records. However, there are cases where I need to use this method to
populate a MyExtendedBaseC ollection. But here's the catch -- I want my data
layer to be unaware (and independent) of MyExtendedBase and
MyExtendedBaseC ollection.

I have tried several different ways to accomplish this, but no matter what I
do, I end up needing to up-cast MyBase to MyExtendedBase, which is illegal
in C#. I need my data layer to be able to accept and populate a
MyBaseCollectio n (with it possibly being a sub class of a
MyExtendedBaseC ollection) with MyBase objects (with them possibly being sub
classes of MyExtendedBase) , and then when the collection is returned, the
items in the collection are of the appropriate type (depending on the type
of collection passed in).

I have read about different design patterns (namely Decorator and
Composite), but am not sure if they apply to my situation, and if so, how to
implement them accordingly.

Again, I may be doing something totally illogical, so I'm open to any
suggestions you may have. Also, if I have not provided enough info, let me
know and I will follow up.

Thanks in advance.

Jerad

[dkode]

I think your're pretty close. If you have a base class, then you should
have no problem passing MyExtendedBaseC ollection as a MyBaseCollectio n
object. This is the power of polymorphism.

A couple of your statements:

need my data layer to be able to accept and populate a
MyBaseCollectio n (with it possibly being a sub class of a
MyExtendedBaseC ollection) with MyBase objects (with them possibly being sub
classes of MyExtendedBase) ,

MyExtendedBase and MyExtendedBaseC ollection are sub classes of MyBase
and MyBaseCollectio n.

When you say a "subclass" it means that it inherits from a base class
or abstract class. I think you have the terminology backwards.

If you are trying to cast MyBase to MyExtendedBase, this is not going
to work. When you need to pass around a specialized type of class, but
dont want to code additional methods (apart from special functionality)
then you cast your dervied or subclasses (MyExtendedBase ) to type
MyBase, you can then pass it around as normal, any methods that are in
the base class that you override in the subclass, can be called as
normal because both the base class and sub class have definitions for
those methods.

Another way to accomplish this would be to use interfaces.

As far as the design patterns, this is something I am still learning as
well, I have found that if you dont understand the design pattern
completely, then dont use it at all. because chances are is that you
will miuse the pattern, and create more headaches then solutions.

hope my comments help!

[Helge Jensen]

Jerad Rose wrote:

do, I end up needing to up-cast MyBase to MyExtendedBase, which is illegal
That's a down-cast. It's "legal" (staticly valid), but if the actual
object instance casted is not an instance of MyExtendedBase the cast
will fail and throw an exception.
Again, I may be doing something totally illogical, so I'm open to any
suggestions you may have. Also, if I have not provided enough info, let me
know and I will follow up.

Let the data-layer, that should be generic in the types, accept the
data-structure to fill items into as an argument. If your data layer
needs to construct "unknown" type objects from data you can have a look
at the factory-pattern. The data-layer can accept, as a parameter, a
factory that is given the data to parse and create an object from that.

BTW: Are you in C#1 or 2?

Decorator and composite are completely unrelated to your problem.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Bob]

Hi Jerad,
You only need one collection. The one for the base class.
When you're pulling in data from the database test the attribute(s) that
mark the difference between Mybase and MyExtendedBase before instantiating
the object that you are going to add to the collection.
bool MyDatabaseGetRo utine(ref collection col)
{
SQlDataCommand etc setup.
MyBase b;
While MyDatareader.re ad
{
If(MyDataReader .GetString(say5 ) == dbNull) //Instantiate a MyBase
b=new MyBase();
else // Instantiate a MyBaseExtended
b= new MyBaseExtended( );
// Now fill the common (MyBase) properties
b.Common1 = MyDataRead.GetS tring(0);
b.Common2 = MyDataRead.GetS tring(1);
Test again for type.
if (b.GetType().To String()=="MyBa seExtended")

{

// Fill the extended properties

}

col.add(b); Adding to collection regardless of Instantiation.

When you come to use the collection iterate across it with a base type
variable

bool LetsUnpackIt(co llection col)

foreach (mybase b in col)

{

if (b.gettype().To String()=="MyBa se")

//Do the mybase things

else

// Do the myBaseExtended things

HTH

Bob

"Jerad Rose" <[e-mail]> wrote in message
news:ea******** ******@TK2MSFTN GP09.phx.gbl...

I'm relatively new to C# and polymorphism, so what I'm trying to accomplish may not be possible, or there may be a totally different approach that I
should be taking.

I have a base class (MyBase) and a collection of MyBase objects
(MyBaseCollecti on). Now, I also have an extension to MyBase (MyExtendedBase : MyBase) that has additional properties. And lastly, I have a collection
of MyExtendedBase objects(MyExten dedBaseCollecti on : MyBaseCollectio n).

I have a data layer that has a method (GetMyBaseColle ction) that retrieves
records from the database, and populates a MyBaseCollectio n with these
records. However, there are cases where I need to use this method to
populate a MyExtendedBaseC ollection. But here's the catch -- I want my data layer to be unaware (and independent) of MyExtendedBase and
MyExtendedBaseC ollection.

I have tried several different ways to accomplish this, but no matter what I do, I end up needing to up-cast MyBase to MyExtendedBase, which is illegal
in C#. I need my data layer to be able to accept and populate a
MyBaseCollectio n (with it possibly being a sub class of a
MyExtendedBaseC ollection) with MyBase objects (with them possibly being sub classes of MyExtendedBase) , and then when the collection is returned, the
items in the collection are of the appropriate type (depending on the type
of collection passed in).

I have read about different design patterns (namely Decorator and
Composite), but am not sure if they apply to my situation, and if so, how to implement them accordingly.

Again, I may be doing something totally illogical, so I'm open to any
suggestions you may have. Also, if I have not provided enough info, let me know and I will follow up.

Thanks in advance.

Jerad

[Jerad Rose]

Thanks for the responses, guys.

To clarify on a few comments:

dkode wrote:

When you say a "subclass" it means that it inherits from a base class or abstract class. I think you have the terminology backwards.
Yeah, I guess I was thinking the "subclass" would be the more generic one
and have fewer members, sort of like a subset. Thanks for the
clarification.

dkode wrote:
I have found that if you dont understand the design pattern completely, then dont use it at all.
I tend to agree with you there, which was why I wouldn't have used them
unless somebody could have helped me understand them.

Helge Jensen wrote:
That's a down-cast. It's "legal" (staticly valid), but if the actual object instance casted is not an instance of MyExtendedBase the cast will fail and throw an exception.
Yeah, that's what I meant (see example below). But I did get the
up-/down-cast confused. But I think I've seen other people posting this
backwards as well.

Helge Jensen wrote:
The data-layer can accept, as a parameter, a
factory that is given the data to parse and create an object from that.
It seems this is the recommended way to go. And I had thought about going
this route originally, but the thing I don't like about using a factory is
that my data layer is dependent on this factory, which it turn is dependent
on my extended class -- which I was trying to avoid. However, I understand
this may be my only option.

Helge Jensen wrote:
BTW: Are you in C#1 or 2?
1.1

Bob wrote:
You only need one collection. The one for the base class.
Theoretically true, but I want my collections to be type-safe, so that
casting isn't required to access the extended members. However, if doing
this would remove the dependence of my data layer on my extended class, I
would go this route.
When you're pulling in data from the database test the attribute(s) that mark the difference between Mybase and MyExtendedBase before instantiating the object that you are going to add to the collection.

This is similar to the factory concept, and requires the same dependency of
my data layer on my extended object/properties. The data layer will not
need access to any of the extended properties, so I would prefer to not
require this dependency. But again, I may not have that option.

Repeating what I said in my original post, here is my setup:

MyBase

MyBaseCollectio n

MyExtendedBase : MyBase

MyExtendedBaseC ollection : MyBaseCollectio n

I can pass an instance of MyExtendedBaseC ollection to the data layer, caste
as MyBaseCollectio n. But when my data layer creates new MyBase objects and
adds them to the collection, there's no way I can down-cast them to
MyExtendedBase when I return from the data layer. I would think there would
be a way to have a base collection get populated with base objects, without
introducing the dependency of the underlying method on the extended
class/collection. It seems this would be a common need, but it sounds like
my options aren't as elegant as "best practices" encourage.

Dkode, you mentioned interfaces. Would the use of interfaces help
accomplish my goals?

Thanks again.

Jerad

[wfairl]

If you want "type safety" (more likely you want to avoid the upcast
here) then you should consider a move to 2.0 and generics. You can do
something similar to this, I've done it in my own data
objects/collections

Something like:
MyBaseObj{ }
MyBaseCollectio n<T> : ICollection<T> where T : MyBaseObj
{
public T this[int index]
{
get
{
...
}
}

...
}

Then MyDerivedObj :MyBaseObj for your derived record obj
and MyDerivedCollec tion : MyBaseCollectio n<MyDerivedObj > for your
derived collection of derived record objects

[dkode]

Thats interesting how you accomplish this with generics. I need to read
up more on generics. All I have used them for is for a List collection
within another class. What does using the <T> accomplish? You don't
have to specify the type?

[Jon Skeet [C# MVP]]

dkode wrote:

Thats interesting how you accomplish this with generics. I need to read
up more on generics. All I have used them for is for a List collection
within another class. What does using the <T> accomplish? You don't
have to specify the type?

You don't specify the type when writing the generic type; you specify
it when you *use* the type.

It's well worth reading up on generics - it's a massive topic though!

Jon

[Jerad Rose]

For those interested, I am posting below what ended up being the ultimate
solution I came to. This accomplishes both of my goals:

1) Type safety
2) Independence of data layer on extended classes

Your feedback is welcomed and appreciated.

Thanks.
Jerad

//Polymorphic Collections Example

public class MyBaseClass
{
//base member implementation
}

public class MyBaseCollectio n : ICollection
{
protected ArrayList _innerList;

public MyBaseClass this[int index]
{
get { return (MyBaseClass)_i nnerList[index]; }
}

public virtual MyBaseClass AddNewItem()
{
MyBaseClass newBaseItem = new MyBaseClass();
_innerList.Add( newBaseItem);
return newBaseItem;
}

//standard collection member implementation
}

public class MyExtendedClass : MyBaseClass
{
public string MyExtendedPrope rty
{
//get/set implementation
}
}

public class MyExtendedColle ction : MyBaseCollectio n
{
public new MyExtendedClass this[int index]
{
get { return (MyExtendedClas s)base._innerLi st[index]; }
}

public override MyBaseClass AddNewItem()
{
MyExtendedClass newExtendedItem = new MyExtendedClass ();
_innerList.Add( newExtendedItem );
return newExtendedItem ;
}
}

public class MyDataLayer
{
public void GetRecords(MyBa seCollection myBaseCol)
{
//database implementation

while(dr.Read() )
{
//This is critical -- using the collection's AddNewItem
//to instantiate the object will ensure the proper type
//is being instantiated. If the collection is an
//instance of MyExtendedColle ction, it will create and
//add an instance of MyExtendedClass to the collection.
//Otherwise, it will add an instance of MyBaseClass.

MyBaseClass myBase = myBaseCol.AddNe wItem();

//set myBase's base properties
}
}
}

public class TestClient
{
public void Main()
{
MyDateLayer myDL = new MyDataLayer();

//This will pass an instance of a base collection to the data layer
MyBaseCollectio n myBaseCol = new MyBaseCollectio n();
myDL.GetRecords (myBaseCol);
myBaseCol[0].MyExtededPrope rty = "Not legal";

//This will pass an instance of an extended collection to the data
layer
MyExtendedColle ction myExtCol = new MyExtendedColle ction();
myDL.GetRecords (myExtCol);
myExtCol[0].MyExtededPrope rty = "Legal";
}
}

[dkode]

I have a quick question about your implementation.

Doesn't this violate n-tier design because the datalayer has knowledge
of the business layer objects? I thought the data layer was only
supposed to return records (DataReader) in this instance, or is all of
this code in your data layer?

From other NG postings, I've had people tell me that the Data Layer has

NO knowledge of business layer objects, doing so violates proper N-Tier
design and tighly couples your business layer with your data layer.