Uploaded image for project: 'Commons Geometry'
  1. Commons Geometry
  2. GEOMETRY-93

Better SubHyperplane Hierarchies

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Done
    • None
    • None
    • None

    Description

      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            mattjuntunen Matt Juntunen
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: