That's about it. The SCA spec says that you actually get instances of e.g. ComponentContext so we need to delegate to the ComponentContextImpl. As SDO was returning pointers inheritence works fine.
Cheers, On 14/08/06, Edward Slattery <[EMAIL PROTECTED]> wrote:
In the case of SDO, it was just the logical pattern for implementation hiding. The implementation was fine up to the point where we wanted to start thinking about the static SDO api, and were proposing to allow code generators to inherit from some DataObject base class and add their own methods such as "getName()" etc. We cant do that with DataObject, as all the DataObject pointers given out are really DataObjectImpls. The prototype code I put in the test directory uses containment instead of inheritance to allow a MyDataObject to contain a reference to a DataObject, and delegate its DataObjectish behaviour. cheers, Ed. On 11/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > I noticed two different patterns in the definition of the public SCA and > SDO API classes. > > SCA: > A delegation pattern where the public API class delegates calls to an > implementation class. > For example ComponentContext contains a private pointer to > ComponentContextImpl. ComponentContextImpl implements the methods from > ComponentContext but does not extend ComponentContext. > > SDO: > Inheritance, where the implementation class extends the public API class. > For example DataFactoryImpl extends DataFactory. > > Is there any particular reason for the two different patterns? Any > advantages or issues with one compared the other? > > A related question. What do you think about reorganizing the folder > structure a little to clearly separate the spec includes from the > implementation specific ones? > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- Pete
