Hello Jody
This is a pleasure to fully agree :) Less subclassing and more aggregation is
one of the "good practices" recommanded in Joshua's Blosh "Effective Java" book
(a kind of bible for Java developpers).
In the particular case of Circle/Ellipse however, the subclassing would still
appropriate since a Circle is really an Ellipse, so every classes accepting an
Ellipse should also accept a Circle. It still appropriate to keep the two axis
methods since they just returns identical values in the Circle cases.
Instead of "Circle has less properties", I should have said "Circle has more
constraints" that make some properties redundant, but not invalide.
In GeoTools, an analogy could be "IdentityTransform extends LinearTransform"
since the former is a special case of the later where scale=1 and offset=0.
Those two properties (scale and offset) become useless since their values are
hard-coded and frozen (so we could said that IdentityTransform has less usefull
properties), but nevertheless still perfectly valid and exact, so it is safe to
query them.
Cheers,
Martin
Jody Garnett a écrit :
> Hi Martin? A discussion on OO Design ... here?
>
> Let me offer a complementary view. The development of deep class
> hierarchies (as with your Ellipse/Circle example) is one of the
> unintended consequences of using subclassing for everything. Especially
> in the case where you are going after code reuse; try making use of
> aggregation more (a LOT more). In this scheme Circle would still
> implement shape; but would make use of a contained Ellipse field; a
> single setR() method would be provided and the rest of the interface
> would make calls on the contained Ellipse. Why do this? People find a
> broad / shallow class hierarchy much more approachable. And this
> technique prevents additional methods being made visible to the user
> (the two axis methods) and strictly limits the user to the single
> setRadius method.
>
> Also for classes that are intended to be used in a dynamic fashion; you
> will need to provide some runtime description so that code can know what
> "optional" methods are safe to call. Experimenting and getting a
> NotImplementedException (or IllegalStateException) is not cool.
>
> Cheers,
> Jody
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
