In a fit of lazyness (I mean reuse) David recycled the DTO objects as delegates inside of the global classes.
While saving mere minuets of development time, we are starting to see a lot of friction along the seems. Witness FeatureTypeInfo's lazy creation of AttributeTypeInfo based on AttributeTypeInfoDTO delegates and dynamic AttributeType information provided from the DataStore.
This friction will increase as WFS and WMS take on more functionality.
CodeHaus Comment From: jgarnett - Time: Thu, 5 Feb 2004 17:34:05 -0600
<p>3.3.4 Remove Data Transfer Object Delegates</p>
<p>Several classes in the global package have taken to making use of an internal
Data Transfer Object as a delegate. This approach provides a level of code reuse,
and lacks many of the drawbacks of sub-classing discussed earlier.
Some of the more apparent drawbacks to this approach include:</p>
<ul class="alternate" type="square">
By definition a DTO object provides a fine level of detail; it is used to group a
collection of configuration information for communication. Direct delegation
to the DTO object results in an unwieldy Application Object that requires
client code to access several properties to discern state.</li>
By directly using the DTO provided as part of the configuration process, an
application is tempted to present information that it may be unable to deliver.
This is most often seen when accessing dynamic content.
When the above limitations are recognized, making use of a delegate can be made
to work. In the interests of maintaining a public code base we would like to
phase out this approach.</li>
CodeHaus Comment From: dzwiers - Time: Wed, 11 Feb 2004 20:08:41 -0600