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 Martin Desruisseaux wrote: > I feel that I should remind a point of object oriented programming: > > There is many way to see subclassing. The vision adopted by ISO specification > (which is also the vision that I suggest to adopt) is in the sense of > "specialization", not necessarly "having more attributes". Thinks verb "to > be", > not "to have". Sometime a subclass has *less* attributes than the parent > class. > > Example given by ISO 19107 (geometry): Circle extends Ellipse, because a > Circle > is an Ellipse in the special case where the minor and major axis have the > same > length. But it has *less* attributes: Ellipse have 2 (the axis length), > Circle > have only 1 (the radius). > > So subclassing is not for "have some optional attributes". If we had this > approach with ISO 19115, the ~100 metadata interfaces (full of optional > attributes) whould explode in thousands of interfaces. > > Martin > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
