|What I mean is, it seems pretty useless to make a Bee and Flower class that inherit from a LivingThing class and then have the interaction code for Flowers and Bees in the LivingThing class.|
The Pollinate code is in the Bee class. The Living class has a virtual function declaration of PollinateMe. The Animal class has a PollinateMe function that returns false. Flowers have their specific PollinateMe functions in their own class.
Just wondering whether this is a trade off - RTTI or casting, versus virtual function declarations in a base class, with virtual function definition where needed.
With the Units conversion tree, I had the strategy of always converting (by calculation) from the original unit to an intermediate unit, then to the target unit. For example, to convert from yards to feet, I convert from yards to metres (always metres, no matter what the original was), then from Metres to Feet. It seems strange at first - why not just divide by 3.0? The answer is that, if there are n original units (metric say) & n target units (imperial) and I want to be able to convert between any of them, I now only need 2(n-1) conversion functions, as opposed to n squared conversion functions.
I should also point out that next level in the Units tree would have CDistance, CAngle, CArea, CVolume etc. Then after that there is specific units classes like metres, feet, yards,mm, cm etc. It is at this level the conversion functions exist.
And, all values used by the code are forced to go through this conversion process - there is no where I use a double as an argument to any function. Values used by the code everywhere are always the metric base units like metres, radians, Sqmetres etc. I don't even keep the original value, it's easier not to keep track of it, and convert it back again on output.
Once input conversion is done, there is no need to do any more conversion, until output conversion is needed.
So for this question:
|...... but what if you wanted To/From English and To/From MyNewUnit and To/From ThatGuysUnits? Would you not then have to adjust CUnits?|
No, because the interface always only needs those 2 functions. And a pointer to CFeet is a valid pointer to CUnits. The virtual functions to convert from Feet to Metres and vice versa are in the Feet Class. Maybe the example is too simplistic to compare to what you are doing, because it only needs 2 functions in the interface.
|At that point, if you called one of the new functions on an instance from a plugin that was compiled before the new functions were added, would that not cause problems?|
As long as any Units plugin extends the Units tree it should work fine, because the actual conversion functions are in the classes that are added, the interface remains the same.
What did you think of my analogy between your code and the Unix System example?
And my Mediator design proposal?
|Basically, I'm trying to make it so that interactions between classes happen as close to the class types in question as possible.|
Well you could have the virtual function definitions much lower down the tree, but you would have to redefine more (all?)of them because they aren't being inherited.
With the idea of having to have an AcquireMe function (that returns false because that is breaking the rules) in the Monster or Enemy class, I am thinking there may be some other funky / clever combination of Design Patterns that might improve this. I did think about putting the Actions into the class that uses them (instead of an Action tree), but the Execute function in Mediator needs to be declared with a pointer to Action. Might need to ruminate on that a bit more.
|I appreciate your arguments, they get me to face problems that I haven't yet but that i would eventually run into later. I've solved tiny majority now, the rest should be the easy part - rendering (oh the pain! The agony!).|
It is good for me too, most of my stuff is mathematical - converting a formula to code is not that hard generally. Other things I am designing involve storing 5 million 3d points, but still be able to carry out operations on any subset of those.
Anyway it's 3.15am again here in Melbourne, Australia, so I will sign off for now. Cheers