Yes, the wrapper base is very common pattern.
Thanks for explaining, makes sense to me now, given that we will end up with least impact on delegating implementations
like yours, when we add a 'contract' method to ChangeManager.
Thanks,
Prakash
On 3/10/2011 9:51 AM, Andy Schwartz wrote:
Hi Prakash -
On Wed, Mar 9, 2011 at 6:56 PM, Prakash Udupa<[email protected]> wrote:
How does the wrapper help any more?.
Let's take a closer look at the use case that I am hoping to address...
I want to write a ChangeManager implementation that:
1. Delegates all of the real work to some other ChangeManager.
2. Examines ComponentChanges as they are added and drops certain
changes that I do not want to save.
I can do this today by writing my own wrapper class that extends
ChangeManager directly and provides delegating implementations of all
of the ChangeManager methods.
However, if we later add some new method to the ChangeManager contract
(as we did with applySimpleComponentChanges()), my wrapper class would
need to be updated - ie. I would need to add yet another delegating
method implementation for the new API. This is annoying and fragile.
On the other hand, if we introduce a base wrapper class in Trinidad,
my concrete wrapper subclass is not impacted by new additions to the
ChangeManager API. Any time we add a new method to the ChangeManager,
we would add an equivalent implementation to the ChangeManagerWrapper
base class. In addition to reducing the amount of work to implement a
ChangeManager wrapper class (no longer need to re-implement every
ChangeManager method), we have significantly reduced the risk of
breaking such classes as the API evolves.
FWIW, this approach of providing a base wrapper class is a very common
pattern. (As Pavitra hinted at this, is used all over the place in
JSF.)
Andy
