ExtendedObjectTcl provides MixIns which are classes that can be mixed into other classes or objects dynamically. This has the effect of being able to add methods to another class or object outside of the class hierarchy. I have found that mixins allow the separation of "object abilities" or groups of common methods out of the class definition. Since ExtendedObjectTcl is fully dynamic mixins can be added or removed from a class or object at will. This allows the object to move through its life and acquire and lose different abilities as it goes.
Therefore much of my code has evolved into:
Class SomeAbility SomeAbility instproc someMethod { } { ... } Class Something Something instmixin SomeAbility Something parameter { varA varB varC }This code creates the class Something with the method someMethod. At first this is strange, but it allows the class hierarchy to reflect the true nature of the OO design and the abilities can be added on after. This is similar to AspectOrientedProgramming, but it seems that all methods become part of some mixin.
-- BenThomasson
The code snippet above implies that the means by which SomeAbility is implemented are always the same, but this may not be true. For instance (illustrated in a CeePlusPlus-ish hodgepodge of pseudocode):
struct FmTunerInterface { virtual void SetFrequency(float megahertz) = 0; virtual void SelectPreset(int button_index) = 0; }; class AnalogFmTuner : public FmTunerInterface { public: void SetFrequency(float megahertz) {/* Rotate variable capacitor to appropriate capacitance to tune circuit */} void SelectPreset(int button_index) {/* Use clever arrangement of levers and pulleys to SetFrequency() mechanically */} }; class DigitalFmTuner : public FmTunerInterface { public: bool SetFrequency(float megahertz) {/* Program appropriate digital value into VCO to mix with input to generate IF */} bool SelectPreset(int button_index) {/* Look up megahertz in table[button_index] and call SetFrequency() */} };...the point being that the ability to implement a particular feature doesn't mean the feature is necessarily implemented in the same way. -- MikeSmith
But wouldn't you use normal method inheritance for that? -- KristofferLawson