05-04-2018 03:47 AM
Hello everyone,
This is not actually a question about a specific piece of code, but rather a discussion on a general programming technique.
The situation is as follows: I'm coding with OOP, and I have a data structure that includes nested classes, as exemplified in the attached picture Nested classes.png (let's say level 1 = A class, level 2 = B class, level 3 = C class); this means that if I need to write data of C class I have to create the following code (see the attached snippet Example.png; an A class is stored in a dedicated Data Value Reference):
What I was wondering about is if I can make B inherit from A and C inherit from B in order to need just a single level of accessors whichever of the three classes I need to edit. This thought raised after coming across some class hierarchy trees with lots of child levels on the web (see attached pictures LV class hierarchy 1.png and LV class hierarchy 2.png), whereas I've never coded more that 1 level of inheritance before.
For example, let's imagine the following structure as it would be with nested classes:
If I create an inheritance tree as I supposed before I would possibly be able to type-specify an instance of Car.lvclass into Tyre.lvclass in order to edit tyre properties without needing to read element of tyre + write tyre properties + write element of tyre (even more so for gears and cylinders).
What puzzles me is this: with such an approach, how can I specify that Car.lvclass is composed of exactly 4 elements of Tyre.lvclass, 1 element of Engine.lvclass that includes 4 elements of Cylinder.lvclass and so on, without duplicating the general information about the car (model, etc.) for each instance of a child class? Or, in other words, how can I keep track of the logical data structure of my system? And also, are there other drawbacks in this technique that I am currently missing?
If someone has experience with something similar, any contribution will be appreciated.
05-04-2018 05:01 AM - edited 05-04-2018 05:04 AM
I think it would be a terrible idea.
There are three relations in OO: "Is a ...", "Has a ...", and "Uses a ..." . "Is a ..." is typically inheritance.
If you can't say "Class B is a Class A", you should not use inheritance. A car is not 4 tires, so inheritance does not make sense. A car has 4 tires, so containment makes sense. These are not rules that are enforced, but if you go against them, your swimming up the stream (e.g. lots of work, little progress).
I'd try to get rid of the DVR's, they are usually a great idea until they become annoying (need an init, hard to debug, not persistent, extra code to access).
But if you do "allow" DVR's, you can make C objects use a DVR. Then you could keep a list of C's, and embed them in B, and embed B in A. Since C works by reference, you can change them from the list, and they will be modified in B as well, since they are the same object. Not my cup of tea, but it will work.
This is not the required way to do it (it's just how you chose to do it):
You can also (using Car, Engine, Shaft as example):
This does indeed mean changing anything in the lowest contained class (Shaft), requires methods in all owners (Engine and Car). You can do (complex) things to prevent that, but usually this works fine. It works fine because it's simple and reflects reality.
Alternatively:
This is also simple and reflecting reality, just a different reality. It's almost how a mechanic would do it (he won't actually tell the car to return the engine, but anyway).
Just try to pick a winning method and try to stick with it. Mixing these techniques can really confuse a program.
05-04-2018 05:44 AM
First of all, thanks for the time you spent on this. I started reasoning about that possibility because otherwise it would not be easy to me to figure out which application may have so many levels of inheritance as the ones exemplified in the two LV class hierarchy that I attached in my first post, so I thought maybe those programmers made that for a purpose that may have been slightly different from pure inheritance; it was an hypothesis I tried to proof here.
05-04-2018 06:33 AM
@Cente90 wrote:
First of all, thanks for the time you spent on this. I started reasoning about that possibility because otherwise it would not be easy to me to figure out which application may have so many levels of inheritance as the ones exemplified in the two LV class hierarchy that I attached in my first post, so I thought maybe those programmers made that for a purpose that may have been slightly different from pure inheritance; it was an hypothesis I tried to proof here.
The resolution of the first hierarchy is not high enough to read. The second one seems to have pretty pure inheritance.
Note that inheritance is just one way to specialize. If all those child DAQ devices (hierarchy 2) are almost the same (childs only added for "purity") an enum in their parent might have been a better choice.
05-04-2018 07:27 AM
Yep, you are definitely describing a "Has a" relationship, which means composition is the proper relationship.
I highly recommend this book if you really want to use OOP effectively: The Object-Oriented Thought Process
As far as multi-level inheritance, I have not ran into the situation yet in the real world. I can imagine a few situations where it could be used though.
05-04-2018 08:04 AM
@crossrulz wrote:
I highly recommend this book if you really want to use OOP effectively: The Object-Oriented Thought Process
One of the good books. I can also recommend Object-Oriented Analysis and Design, Booch. I'd buy a used copy, or 2nd printing for only a few $ (few good chapters (UML) missing though).
@crossrulz wrote:As far as multi-level inheritance, I have not ran into the situation yet in the real world. I can imagine a few situations where it could be used though.
I use multi level inheritance at more then a few places. No problem.
I think the problem here is multi level containment. That can be a pain. If it makes you feel better: imagine doing anything similar without OO...
05-04-2018 08:51 AM
wiebe@CARYA wrote:I use multi level inheritance at more then a few places. No problem.
Never said it would be a problem. Just stating that it is not exactly common in test oriented systems. Again, that is based on my experience.
wiebe@CARYA wrote:
imagine doing anything similar without OO...
*shudder*
05-04-2018 09:09 AM
@crossrulz wrote:
wiebe@CARYA wrote:I use multi level inheritance at more then a few places. No problem.
Never said it would be a problem. Just stating that it is not exactly common in test oriented systems. Again, that is based on my experience.
I figured "situation"="problem". I'm not working on typical test systems, but test systems non the less.