[
https://issues.apache.org/jira/browse/GEOMETRY-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen updated GEOMETRY-93:
----------------------------------
Labels: beta1 (was: )
> 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
> Priority: Major
> Labels: beta1
>
> 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)
