Hi Martin: > I'm trying to find a proper name for a new class acting as a "Decorator" or > "Wrapper". In GeoTools trunk, we have 5 classes ending with "Decorator" suffix > (ReadonlyAttributeDecorator, LongitudeFirstEpsgDecorator, etc.) and 6 classes > ending with "Wrapper" suffix (DBCPUnWrapper, FilterVisitorFilterWrapper, > etc.), > so I'm not sure we have an agreement. > There are several options for applying a wrapper (even within the bounds of the design pattern book): - Decorator is a wrapper that supports the same interface as the original. So LongitudeFirstEpsgDecorator wraps an EpsgAuthority and is also an instanceof EpsgAuthority. The focus is on adding on functionality. - Adaptor is a wrapper that supports a different interface than the origional - this focus is on changing interface rather than adding on functionality. - Proxy is a wrapper that supports the same interface as the original and acts as a stand in (usually for lazy loading or remoting). Wrapper is the general practice of encapsulating an original object; Decorator and Adaptor focus on two different reasons for using a Wrapper. Proxy is the most tricky use of a wrapper (since often it is responsible for creating the thing being wrapped). > Some observations: > > * "Decorator" and "Wrapper" seem synonymous in Design Pattern. > Decorator is one use of a wrapper; think of wrapper as the coding practice, and Decorator as the reason why. > * JDK 6 never use "Decorator" or "Wrapper" in the Design Pattern sense: > - It doesn't use "Decorator" at all, in no public class. Actually most > decorators in JDK have no special suffix at all (e.g. "java.io.*"). > - It sometime uses "Wrapper" but rather in the sense of what > Design Pattern call "Adapter". So maybe there is a risk of confusion. > That is fine; it is just being more specific. > - It sometime uses "Proxy" in the "Decorator" sense: > * java.util.EventListenerProxy > * java.awt.event.AWTEventListenerProxy > * java.beans.PropertyChangeListenerProxy > * java.beans.VetoableChangeListenerProxy > > In some of my previous code, I used "Adapter" in a way that seems to disagree > with Design Pattern usage, so I need to change my vocabulary. "Wrapper" seems > confusing since it is used both in the "Decorator" and in the "Adapter" sense. > "Decorator" may be more accurate, but I'm not a big fan of this name because > it > seems to have historical root in GUI Windows (adding title or scrollbars to an > existing Window, etc.). That is just the example in the book; adding security checks to a web service is also commonly done with a decorator. Indeed spring AOP almost entirly is focused as generating these decorators on the fly using the java dynamic proxy facilities. > A BufferedAuthorityFactory for example (basically > renamed "CachedAuthorityDecorator" on trunk) do not "decorate" authority or > CRS > objects. > I named this one correctly; I am decorating the original authority and adding caching (ie new functionality) to it. > Do we have a policy in GeoTools? Do I'm the only one unconfortable with > "Decorator" suffix? Do we have alternative? Is a suffix required in all cases? > What peoples things about the current practice in java.io.*, which is no > suffix > at all but just name telling which functionality this class brings > (BufferedInputStream, DeflatedInputStream, PushbackInputStream, etc.)? > I would be fine taking that approach; however I *do* like leaving these pattern names in since they explain a great deal about what roll the class plays in the running application.
Cheers, Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
