Hi!
The current approach adds interface ConversationBinder, and a setter
method has been added to the Conversation class. Each
dependency-injection-specific layer then provides a different
implementation of this (eg SpringConversationBinder) when creating
Conversation instances.
An alternative would be for each dependency-framework to instead
return a subclass of Conversation, then the binder interface would not
be needed.
A simialar pattern I tried to achive with the framework adapter, you
have a basis class everyone can inherit from and implement the required
functionality.
IMHO the framework adapter shows the bad side of that pattern. The
framework adapter just collects various aspects of the used framework
and tries to provide a common api for Orchestra.
When we think of "aspects" here, it would have been better to build
small pieces for each aspect of the framework (spring, jsf, jsp, junit)
and let the framework adapter just delegate to them.
Said that, I think your ConversationBinder is in the same category of
patterns.
The Conversation object itself is not bound to, nor does it depend on,
any environment. Going the subclass way will change that. Now the
Conversation instance itself depends on Spring then.
What, if in the future we are going to add other aspects to the
Conversation which then depends on JSF?
Without multiple inheritance we might end up with many different
conversation implementations.
I'd keep your solution (ConversationBinder interface) which will become
much more powerfull the more aspects we add to the Conversation.
Ciao,
Mario
