Re: Simple Inheritance : Creating derived classes from instances of base class.

Tech-Archive recommends: Speed Up your PC by fixing your registry

why don't you write an operator that converts animals in tagedAnimals?

nyathancha@xxxxxxxxxxx schrieb:

Hi,
Thanks for the replies guys. No, my interest hasn't waned yet. After
the friday evening post, i had some stuff to do on saturday morning
before I checked the newsgroups again in the evening. Sorry about the
delay :-)

First of all "Animal" is an example, maybe I should have used
"customer" with the northwind database as a reference.

Tom, I did consider using the decorator pattern. You are right in some
ways the methods that take the base "Animal" wouldn't know about the
"TaggedAnimal" class anyway and I could just pass them the animal I get
from "TaggedAnimal.GetAnimal()". But the problem is when I am binding
the object to a control such as a GridView, I want to display the
properties from the "TaggedAnimal" class as well as the base class.
This means that each of the properties in the base class would have to
be exposed as a property in the derived class. So, the TaggedAnimal
would look something like

public TaggedAnimal
{
Animal currentAnimal;
public TaggedAnimal(Animal CurrentAnimal){currentAnimal =
CurrentAnimal;}

public string Weight {get {return currentAnimal.Weight;}}
public string Height {get {return currentAnimal.Height;}}
/* etc. etc. Plus there will be Tagged animal specific properties. */

}


The problem with this approach is that every time I change the
underlying database, say by adding another column "BloodType", I don't
just have to use the ORM tool to regenerate my ORM DB layer, I will
also have to change some of the code in my own DB/Business Logic layer.
Basically with a new column, I would have to go back and change the
TaggedAnimal class to

public TaggedAnimal
{
Animal currentAnimal;
public TaggedAnimal(Animal CurrentAnimal){currentAnimal =
CurrentAnimal;}

public string Weight {get {return currentAnimal.Weight;}}
public string Height {get {return currentAnimal.Height;}}
public string BloodType {get {return currentAnimal.BloodType;}}
/* etc. etc. Plus there will be Tagged animal specific properties. */

}

And I have to do that everytime I make some change to the underlying
database, which is exactly what I am trying to avoid by using the ORM
tool.


But if the TaggedAnimal inherited from the Animal class, the data in
the new column would be visible in the TaggedAnimal as well, without me
having to do anything. All I have to do is change the view layer to
include another column in the Gridview that displays the BloodType (or
not even that, if i set the AutoGenerate property to true in the
gridview)


I suppose I can still use the decorater pattern and use the
GetAnimal()."PropertyName" in the boundfield column. Do something like

<asp:BoundColumn HeaderText="Tag" DataField="Tag"></asp:BoundColumn>
<asp:BoundColumn HeaderText="Height"
DataField="GetAnimal().Height"></asp:BoundColumn>
<asp:BoundColumn HeaderText="Weight"
DataField="GetAnimal().Weight"></asp:BoundColumn>

Does the Gridview allow for calling methods as part of the datafield?
Need to try it out.


Nonetheless, It still seems to me that a good "design" for this calls
for the use of inheritance rather than composition. The functionality
that I am adding is basically transforming/manipulating a small bit of
data in the underlying class. This shouldn't require me to change the
type of the class itself. In a way, it is still an "Animal", I haven't
changed its nature or used it as a part of a larger, different entity.
All I did was add a tiny bit of information/processing on top, so
conceptually it seems to me that it should retain its "Animal" nature
(type).


Bruce,
Forgive me for the use of the example, I see it has made some things a
bit murkier. The property I want to add is not necessarily the same for
all the classes. So I will have to subclass each of the generated base
classes/entities. For example another class (related to the database
table) might be "Equipment". I might want to add a property that
calculates the age of the equipment based on the current time and
"AcquiredDate" property of the Equipment class, then I would do
something similar like

public DatedEquipment : Equipment
{
public DatedEquipment(Equipment currentEquipment) : base =
currentEquipment
{}
public string Age
{
get
{
return (System.datetime.now - base.AcquiredDate).ToString();
/* .. Or something along those lines.*/
}
}


}

Clearly any custom properties/processing that I add to the Equipment
class will be different than that I add to the Anmial class so each of
the class will have to be subclassed again. (For the ones that need
custom properties/processing anyway).

But the problem you posed is very interesting as well, and that would
definitely be a cool pattern (not to mention some killer use of
generics).

The root of my problem is not so much that I need "dynamism" in my
inheritance hierarchy ( I can subclass each class as i said), its more
along the lines of "the base class has already been instantiated (by
the ORM, when i call "ThirdPartyORMTool.GetAllAnimals();"), the type
hierarchy has been defined statically at design time (which is fine),
but now I need to use the already existing base class when
instantiating a subclass"

Thanks again for the help guys, much appreciated.

Tom Leylan wrote:
Animal is almost assuredly just an example. If he is dealing with lots of
different classes then I would suggested the example include Dog(), Cat(),
etc. So basically you think he wants TaggableCat(), TaggableDog(), etc.?
So again can't he just contain these? The Cat and Dog objects are exposed
for what they are when he needs them to be and they have tag functionality
by virtue of their container.

Perhaps his interest has waned or he has solved it another way...

"Bruce Wood" <brucewood@xxxxxxxxxx> wrote in message
news:1169241695.322126.272390@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Tom Leylan wrote:
I believe you recapped it more or less correctly. I'm not sure if they
are
"unrelated" animal types since he expressly mentions an "Animal" base
type.
He can't (apparently) subclass this the way he wants to (or doesn't want
to)
so I thought he might contain them in a specialized TaggedAnimal class
and
be done with it.

Again I certainly don't know for sure :-)

My impression is that the "Animal" thing was just and example. In
reality he's using an ORM, so he'll have lots of different, unrelated
base classes to contend with. At least, that's what I understood.


.

Relevant Pages