Extending a class dynamically, but avoiding the decorator

[CharlesB]

I'm designing a generic motion system, where an motion axis is an class, with Move/getPosition/Home etc.

 

I want to extend its behavior to handle backlash. It requires to extend the move method, so if I don't want to modify the original Axis class to keep it simple and generic, I make an HysteresisAxis class that overrides the Move method, in which correct move commands are issued to correct backlash. Fine.

 

But how do I extend it dynamically? Meaning that given an existing Axis object, I want to enable hysteresis handling by creating an HysteresisAxis object from it? Without manual copy of the private data fields?

 

My only answer is the decorator pattern: the HysteresisAxis actually holds the Axis in private data, and override home, getPosition, etc to invoke the Axis' method. The problem with it is that it requires to recreate all Axis methods as dumb methods that calls the decorated axis, which is a bit far from inheritance original idea...

 

Is there any way to clone an object into its child class, or some other solution to my problem

 

Thanks for your insights

 

Charles

[PaulL]

What you have is that you want to equip an axis instance with a particular algorithm (BasicMove or HandleBacklash) for motion (e.g., Move), and you want to specify that algorithm dynamically without overriding the Axis.move() method, for instance.

 

The Strategy Pattern does just that, by encapsulating algorithms in a separate family.  See http://lavag.org/topic/14213-strategy-pattern-example/?hl=%2Bstrategy+%2Bpattern for a LabVIEW discussion and example.

 

Good luck!

[drjdpowell]

Making a new “MoveStrategy” class tree is my first thought also, but another possibility is to create a HysteresisCapableAxis child class that by default has a Move method that just calls the parent method, but that can also enable hysteresis (via some “Enable” boolean).  You can then enable or disable hysteresis without changing the class.

[CharlesB]

Making a new “MoveStrategy” class tree is my first thought also, but another possibility is to create a HysteresisCapableAxis child class that by default has a Move method that just calls the parent method, but that can also enable hysteresis (via some “Enable” boolean).  You can then enable or disable hysteresis without changing the class.

 

 

It's the pragmatic solution compared to a strategy pattern, but not satisfying from OO desing point of view. LabVIEW can be so frustrating some times...

I really wish I could create this child object from a base class. 

[CharlesB]

I Found the relevant discussion for the "assign parent's data to a child" problem, which allows me to keep my design simple. Strategy pattern is a bit overkill here, and although Daklu's solution (manual copy of parent's private data) in this thread has its drawbacks, it's the simplest solution to me.