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
