You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Matt Juntunen (Jira)" <ji...@apache.org> on 2020/04/18 01:46:00 UTC

[jira] [Created] (GEOMETRY-93) Better SubHyperplane Hierarchies

Matt Juntunen created GEOMETRY-93:
-------------------------------------

             Summary: Better SubHyperplane Hierarchies
                 Key: GEOMETRY-93
                 URL: https://issues.apache.org/jira/browse/GEOMETRY-93
             Project: Apache Commons Geometry
          Issue Type: Improvement
            Reporter: Matt Juntunen


The current subhyperplane classes follow an awkward inheritance hierarchy pattern for Euclidean 2D and 3D and spherical 2D. Each space has a package-private base subhyperplane class (containing public methods), which is extended by a public subhyperplane implementation class and a convex subhyperplane implementation class. For example, in Euclidean 2D we have:

- {{AbstractSubLine}} - package-private base class containing public methods such as {{getLine}} and {{getIntersection}}
- {{SubLine}} - extends {{AbstractSubLine}}; uses a {{RegionBSPTree1D}} to represent arbitrary subsets of the line
- {{ConvexSubLine}} - extends {{AbstractSubLine}}

Not only is it awkward that public API methods are defined in a package-private class, but the hierarchy does not make sense from a naming point of view. For example, {{ConvexSubLine}} is a "subline" geometrically but is not a {{SubLine}} from the class perspective. A better naming scheme would be

- {{SubLine}} - public class; previously named {{AbstractSubLine}}
- {{RegionBSPTreeSubLine}} - extends {{SubLine}}; previously named {{SubLine}} but now with a name that better describes its functionality and implementation
- {{ConvexSubLine}} - extends {{SubLine}}

Similar changes should be made in Euclidean 3D and spherical 2D.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)