General inheritance behavior / best practice wanted [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I have a general design pattern question converning inheritance of objects. No, I don't mean class inheritance like public class dog : animal, I need some "best practice" information on the following situation.

I have three classes of the same type with a name and different values. They have a hierachical order, so one is the parent, first and second child. Let's assume, every class should have a property called color.

I create an instance of a parent class and give it the color "BLUE". Now I create a child of the same type which should inherit all attributes by reference to the parent, as long as there is no special value set. It's not a clone, since I don't want to copy the values into the new class. So every change in the parent is automatically shown in the child.

So I create a new child under the first one - I don't have set any special color to the first one, so my second child is "BLUE", too. In short form it would look like this:

BLUE (Parent) --> BLUE (Child1) --> BLUE (Child2)

Now I change Child1 to "RED":

BLUE (Parent) --> RED (Child1) --> RED (Child2)

This would be a nice way to store only the differences to the base, so in case of large structures, I could simply save storage.

Any best practices for such a contruct / articles to read / links?

Thanks in advance

开发者_开发知识库

Roland

---

Don't know if this has been described before but I would design it like this:

First, give each of your classes a 'property set'. In C++ this could be a map, mapping an identification (string, number, GUID, ...) to a value.

Then, give your classes a getColor method that works like this (this is incomplete code but should be enough to get you started):

PropertySet::const_iterator it = m_propertySet.find("Color");
// property found, return it
if (it!=m_propertySet.end()) return it->second;
// if property is not found, ask our parent
if (m_parent) m_parent->getColor();
// if no parent, return black
return BLACK;

Although this works, there are some pitfalls in this approach:

• looking up values in a property set is much slower than just returning a data member
• using a string as key in the property set is slow, but makes it easier to distinguish your properties
• using an integer as key in the property set is much faster, but can make it more difficult to distinguish your properties
• the property set will always take up more memory than just storing a data member, which probably only makes it feasible if you have a deep hierarchy, with many many properties of which there are only a few set

---

I think this is a case of the Delegation Design Pattern.

Implementation of this kind of behavior depends on the language you are using. Prototype based languages, like Javascript or Self, use this mechanism natively. It means that you can establish a parent-child relation between two objects and immediately the child inherits all parent properties. When you change the value of a property in the parent object, you will see the new value in its children too. If you change a property in a child object, the new value is stored in the child and its parent is not affected.

If you use a language like Java or C++/C# you usually mimic this behavior holding in a member variable of an object (the child) a reference to another (its parent) and put in child's getters the necesary logic to look for a property value stored in the object itself (in a member variable or map), or delegate responsibility to its parent if child can't resolve the property by itself. Usually both child and parent implement a common interface, but I supose it's not always required.