Inheritance - what's your take on this?

lclarsen

Hi, I'm in the process of defining some classes for the elements in a type of listbox control. I'm thinking about having a parent class from which, each element inherits, with common information such as ID, title etc. But the individual elements in the list will have properties that are specific to their own type. Some will have a fileName attribute while others wont. The parent class is handy for sorting operations and other generic tasks, but I will need to differentiate between the instances at some point in my code. Should I have a type attribute in the parent class to tell me what attributes to read for a specific instance? I don't wan't to have virtual members in my parent class that are only meaningful for some instances. Maybe the elements don't have enough in common to warrent inheritance?! BTW, I will not have access to reflection techniques to tell me which type and instance is. Unmanaged C++ to be exact. Thanks.

Mycroft Holmes

lclarsen wrote:

Should I have a type attribute in the parent class to tell me what attributes to read for a specific instance

Down this path lies insanity. I am afraid I go back to my database for my entity definitions, if I can make a view of it then I ain't gonna build it. Taking the attributes structure too far is really difficult to support, you almost need a data dictionary just to find out what you are looking at. I must admit I rarely use inheritance, possibly b/c I don't automatically see the connection between objects.

Never underestimate the power of human stupidity RAH

Lost User

lclarsen wrote:

The parent class is handy for sorting operations and other generic tasks, but I will need to differentiate between the instances at some point in my code. Should I have a type attribute in the parent class to tell me what attributes to read for a specific instance? I don't wan't to have virtual members in my parent class that are only meaningful for some instances.

The code should be using helper-methods from the object, and not refer to specific properties directly. Take the [IComparable](http://msdn.microsoft.com/en-us/library/system.icomparable.aspx)[[^](http://msdn.microsoft.com/en-us/library/system.icomparable.aspx "New Window")] interface; it's the object's that tell the Sort method how to compare the items in order to sort them.

Bastard Programmer from Hell :suss:

Chris Meech

lclarsen wrote:

don't wan't to have virtual members in my parent class that are only meaningful for some instances.

I understand your concern here, but it reminds me of a cooking expression. If you are going to make an omelet, you have to break some eggs. Yes the parent will need to implement a 'default' implementation for each, but that is just the nature of the beast. :)

Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]

Lost User

That's where we separate concerns using interfaces. It's not required for the base to implement all members, we can implement interfaces at a higher level. That way we don't force a specific set of members up the inheritance-chain, and still have the luxury of interacting with a part of the inheritance-set using a common interface.

Bastard Programmer from Hell :suss:

Lost User

You can use interfaces to get around the problem. Each of the child classes implements an interface that it needs to support. And then you can use code like this to check if you need to call some method on the child items.

ItemBase item = listControl.Items[x];
if (item is IFileItem) {
IFileItem fileItem = item as IFileItem;
fileItem.Save();
}

lclarsen

Chris, I guess I was hoping you could offer some powdered eggs or something, so I wouldn't have to break any :) Anyway - the conclusion seems to be there isn't really any perfect solution to this. I somehow suspected that. Thanks for the input everyone :thumbsup:

jschell

lclarsen wrote:

I'm in the process of defining some classes for the elements in a type of listbox control.

This is a display problem.

lclarsen wrote:

The parent class is handy for sorting operations and other generic tasks, but I will need to differentiate between the instances at some point in my code.

This looks like it isn't a display problem. So two possibilities exist. 1. The logic really has nothing to do with the display problem. So what is the problem? 2. The logic is about display. Then it is simple, don't mix display logic and business logic.

Stefan_Lang

The question I always ask myself to find out what kind of relationship two objects really have, is whether it's a 'is a' or 'has a' relationship. E. g. a Mercedes 'is a' car, so it inherits all methods and properties of a generic car. And it 'has a' three-pointed star. You wouldn't inherit a 'Mercedes' from a three-pointed star, would you? ;) Your case sounds more like a 'has a' relation ship, in that all the other classes 'have' an ID, title, etc.. The obvious way would be to just let every class have these members, but if all classes are going to have the same 3 or 4 member variables, then chances are these belong together in a class of it's own. or maybe just a struct:

struct ID {
int id;
std::string title;
};

class MyDialog {
ID id;
// ...
};

class MyButton {
ID id;
// ...
};

Now you need to decide if that is sufficient for the operations you want for these classes. You will get a bit of redundance this way: e. g. accessors for each class that uses ID. But I see no reason to have virtual methods or inheritance.

Lost User

sexy girlï¼video for adult ï¼ more than 30 videos.http://sharecash.org/download.php?file=2531204