[Ctk-developers] XDOM - decorator pattern

[Marco Viceconti]

Dear Paul:
   I hope you do not mind if I put in CC the CTK list, as this  
conversation might be of their interest.

I was not familiar with this pattern, and I found it very  
interesting.  but I disagree on the use in the XDOM story.  If I got  
it right, this is a pattern where you can change at run time un  
particular method in one particular instance of a class, as far as it  
is designed according to this pattern.

So if you have a volume class that support the method spin voxels,  
which makes all voxels to revolve clockwise, you can load runtime a  
decorator in a specific view so that all instances of the volume class  
loaded in that view actually spin counterclockwise.

In creating an extensible data object model (XDOM) however, the  
problem is not to override methods, but to allow the plugin programmer  
to add new methods that extend a template data type.  In this sense I  
believe the bridge pattern is more adequate:
http://en.wikipedia.org/wiki/Bridge_pattern

Still, I think we should give this pattern a closer look, because  
there are a number of cases where it might come handy.

I suspect that the mechanism our colleagues in INRIA described at the  
CTK meeting in Oxford is strongly based on the ability of QTObjects  
and derivative to exchange messages, making simple and efficient the  
use of message-passing mechanisms.  This however creates a strong  
dependency onto QT, which we might want to discourage in CTK (we  
should remember QT already changed license model 2 times :-) ).

Thus, I hope they agree that some lateral thinking on this matter is  
helpful.

Cheers

Marco




Il giorno 4 Nov 2009, alle ore 09:41, Paul Desmedt ha scritto:

> Hi Marco,When you were explaining the XDOM principle it made me  
> think a lot of the decorator pattern,Which is a method to easily  
> extend functionality in which basically the inheritence is bypassed.I 
> ´m not an expert in this so I could be wrong, find below the  
> introduction from wikipedia (http://en.wikipedia.org/wiki/Decorator_pattern 
> ).

> Introduction
> The decorator pattern can be used to make it possible to extend  
> (decorate) the functionality of a certain object at runtime,  
> independently of other instances of the same class, provided some  
> groundwork is done at design time. This is achieved by designing a  
> new decorator class that wraps the original class. This wrapping  
> could be achieved by the following sequence of steps:
>
> 	• Subclass the original "Component" class into a "Decorator" class  
> (see UML diagram);
> 	• In the Decorator class, add a Component pointer as a field;
> 	• Pass a Component to the Decorator constructor to initialize the  
> Component pointer;
> 	• In the Decorator class, redirect all "Component" methods to the  
> "Component" pointer; and
> 	• In the Decorator class, override any Component method(s) whose  
> behaviour needs to be modified.
> This pattern is designed so that multiple decorators can be stacked  
> on top of each other, each time adding a new functionality to the  
> overridden method(s).
>
>

--------------------------------------------------
MARCO VICECONTI, PhD                              
(viceconti at tecno.ior.it)
Laboratorio di Tecnologia Medica              tel.   39-051-6366865
Istituto Ortopedico Rizzoli                            fax.    
39-051-6366863
via di Barbiano 1/10, 40136 - Bologna, Italy

Tiger! Tiger! Burning bright in the forest of the night,
what immortal hand or eye could frame thy fearful symmetry?
--------------------------------------------------
Opinions expressed here do not necessarily reflect those of my employer