I think the separation of concerns is already accomplished by creating the 2 interfaces. However in the case above why would you need 2 separate classes to implement the translator part, since in that instance the production of Y objects is a one-liner once an X is acquired? I agree that at some point it could get more complicated with the requirement for more actors in the middle part, and at that phase you would break the translator into multiple components. That's why you create the 2 interfaces in the beginning, so the rest of your system doesn't break when you have to change the implementation of the translator.
It seems to me that having a single object implement 2 interfaces is not the problem - it is done all the time... "implements Initializable, Configurable, Disposable..." - it's more how do I access the same object through different interfaces using the role manager in cocoon? Thanks for all the help, Simon -----Original Message----- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 11:29 AM To: [email protected] Subject: Re: Same component instance but multiple roles Simon Stanlake napisał(a): > Hi, > I think I have a simpler example that better illustrates the idea of 2 > roles 1 component instance. Think of a producer-consumer application. > A producer component creates objects of type X. It then passes it to a > component - call it the translator - for handling. The translator uses > the X to create an object of type Y. A third component, the consumer, > accesses the translator for objects of type Y when they are available. > > In this application, the translator plays 2 roles, the role of the > input queue for newly formed X objects, and the role of the output > queue for newly formed Y objects. Any component that produces X > objects would access the translator using > > public void addX(X x) > > and any component that consumes Y objects would access it using > > public Y getY() > > These 2 roles should be separated into 2 interfaces, since they are > really separate concerns. However, in the case that the collection of > X objects and production of Y objects is accomplished inside one > component instance, you would want to have 2 roles for the single instance. > Something like... > <snip/> > Anyway, longwinded way of saying I want to do something like this... > > <role name="XStore,YProvider" default-class="Translator"/> > > Appreciate the response - it's nice to know people out there will take > the time to help me out. > The question is what REALLY stops you of creating two components, one for storage and the second for translating and then one would pull the data from another? As you said, these two things are separate concerns so also should be implemented separately. I can imagine situation when number of objects stored in store grows and some persistence on filesystem/database is needed. Then, store component is just gateway to this media's and eventually caches some most frequently used objects. Don't you think separating this two concerns is good design practice? -- Grzegorz Kossakowski --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
