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.
Some observations:
* "Decorator" and "Wrapper" seem synonymous in Design Pattern.
* 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.
- 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.). A BufferedAuthorityFactory for example (basically
renamed "CachedAuthorityDecorator" on trunk) do not "decorate" authority or CRS
objects.
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.)?
Martin
-------------------------------------------------------------------------
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
