Inheritance design issue

[Mark O'Flynn]

I would like some advice regarding implementing inheritance using vb.net.

I have an application written in vb6 that I am rewritting from the ground up
in vb.net to take full advantage of .net, but I have encountered a design
issue implementing inheritance.

To explain my question, I will use an example. I have a Person class, with
properties such as ID, Name, Phone, Address etc. I then have a Manager
class that inherits Person and adds additional properties such as Division,
etc.

I load all the people from a database into an array list as part of a
Persons class.

Now, I want to load the Managers from a table that contains their ID, create
the Manager object with a reference to the Person data, and then load the
manager specific detail.

eg.

Dim oManager as New Manager
oManager = Persons.Find(ID :=1234)
oManager.Divisi on = ...
....
Managers.Add(oM anager)
MsgBox(oManager .Phone.ToString ) ' Show phone number from the base Person
object

Now, this doesnt work as I get an invalid cast exception (as expected).

What I dont want is to create a new Manager, then load it with the data from
the Person Object

eg.

Dim oPerson as Person = Persons.Find(ID :=1234)
Dim oManager as New Manager
With oManager
.ID = oPerson.ID
.Name = oPerson.Name
...
.Division = ...
End With
MsgBox(oManager .Phone.ToString ) ' Show phone number from the Manager object

If Phone is changed in the Person object, this will not be reflected in the
Manager object.

It seems to me that this would be a common situation faces in OOP, so any
advice on how I can get an inheritied object to maintain a reference to the
base object's data, or how best to design a solution would be most
appriciated.

Thanks in advance,

Mark O'Flynn

[Richard Myers]

<David>
<..>

I agree with all those points...except i dont see how you can say:

A person is NOT a manager, and so you shouldn't be creating a
person object when you really want a manager.

In his problem space a Manager might need to be a person....
or at least be personable.

For instance if he has a contact group. He may need to add several
different types
of people/roles to the group so in order to keep the contact group
interface
simple he may need a Person base class. He might be better off
combining the factory method with having all his people implement a Person
interface if he needs to group them in any way.

Go for interface based polymorphism rather than inheritence based.

Richard

[Nak]

> Go for interface based polymorphism rather than inheritence based.

The perfect solution for his needs. Or even as a bodge why not just have an
enumerated type for a person class stating what type of person it is.

Public enum personType
OfficeJunior = 1
Skiv = 2
Manager = 4
BossesPet = 8
Boss = 16
End enum

Could even be a bitwise combination, I've certainly known of it in real
world examples!

Nick.

[Cor Ligthert]

Richard,

How many times did you already made code like this (this is just a sample as
you never would do it by the way)

\\\
Dim mycontrol As Control = ListView1
If TypeOf mycontrol Is ListView Then
DirectCast(myco ntrol, ListView).Multi Select = True
End If
///

The listview is a manager and the Control describes persons

Just as idea

Cor

"Richard Myers" <fa**@address.c om>
..

<David>
<..>

I agree with all those points...except i dont see how you can say:

A person is NOT a manager, and so you shouldn't be creating a
person object when you really want a manager.

In his problem space a Manager might need to be a person....
or at least be personable.

For instance if he has a contact group. He may need to add several
different types
of people/roles to the group so in order to keep the contact group
interface
simple he may need a Person base class. He might be better off
combining the factory method with having all his people implement a Person
interface if he needs to group them in any way.

Go for interface based polymorphism rather than inheritence based.

Richard

[David]

On 2004-11-27, Richard Myers <fa**@address.c om> wrote:

<David>
<..>

I agree with all those points...except i dont see how you can say:

A person is NOT a manager, and so you shouldn't be creating a
person object when you really want a manager.
In his problem space a Manager might need to be a person....
or at least be personable.

Well, a manager IS-A person. It's the opposite that isn't true.

Looking back, perhaps I wasn't clear about that. I think the fact that
manager derives from person is fine. That's what I meant by saying that
there really wasn't an inheritance design problem here. In my example I
still envisioned Manager deriving from Person.
For instance if he has a contact group. He may need to add several
different types of people/roles to the group so in order to keep the
contact group interface simple he may need a Person base class. He
might be better off combining the factory method with having all his
people implement a Person interface if he needs to group them in any
way.

Go for interface based polymorphism rather than inheritence based.

Interface vs. inheritance is an interesting question, but doesn't
address the basic issue of the OP. You can't add an interface to an
object at runtime any easier than you can change the class of an object.

[Mark O'Flynn]

There has been a lot of advice ... thanks to all for your input. My
solution probably resides in a combination of advices.

At the core of my concern was that I expected I could use inheritance to
inherit the 'data' and the 'functionality' . That is, the manager inherits
the persons functions like CalculatePay, CalculateTimeOf f etc, and also
inherit the data, like Name=Mark, Phone=12345 etc (not the property dec but
the referenced data) .

I don't want to implement a Person Interface in my Manager class as I have
to rewrite (copy/paste) the bodies of all functions and properties. The vb6
app worked this way and it has become a maintenance problem. There are many
classes that implemented the Person interface and each one had to copy the
same code to perform the same functions. Also, inheritance is giving me
some other advantages, so I would like to stay with it if I can.

Your inheritance structure is fine here. What you really have is an
object creation problem, which stems from a common situation where the
database structure doesn't map to the class structure very well.

This is correct. The database structure is infact text files used by
another legacy system, and it was not built to map to a class structured
application. This is one constraint that I have.

At this point I am leaning towards passing the Person object into the
Manager constructor. it means that I have to shadow the properties and
functions of the base class, but I can pass the execution to the base class
using mybase.calc.... etc

Anyway, now to implementing some of the suggestions.

Thanks to all for the help.

MOF