Re: Confusion about splitting classes to allow sharing of resources

Responding to M.a.stijnman...

I've been confusing myself with this problem for a bit, and I'm
wondering if I'm going about this the right way. Let me describe my
problem first:

I'm using cubic splines to model two-dimensional parametric curves
(x(t),y(t)) to interpolate between nodes. I have a working Spline class
that does cubic spline interpolation of function values f[i] that are
defined at knot positions t[i]. I use this in my current Curve class.
Along with the splines for x and y, the Curve class also has one for
any other values (say p and q) that need to be interpolated along the
curve. I expect subclasses of Curve to add new interpolated parameters
along the curve. All Splines x, y, p and q currently have their own
knot vector t[i] and the Curve class provides functions that ensure a
certain t[i] of all splines only get changed all at once (in my app the
t[i] sometimes need to change to enhance the parameter mapping of the
curve). This is done by providing a virtual SetKnot function that a
Curve implementation should override. To me, the logical next step
would be, to change the spline class so it supports sharing a knot
vector between splines - it will save storage and will guarantee all
Splines stay in sync. For this, I would add a class KnotVector and give
the Spline class a reference to a (possibly) external knot vector.
Adding new interpolation variables in subclasses of Curve will then
just be  a matter to linking that spline to the same knot vector as
well.

I don't know much about spline interpolation algorithms, so I am guessing a bit here. I assume there is a different interpolation algorithm for p and q than for x and y. I assume that 'node' is the curve viewpoint and a node is always a position (x, y) but may have other arbitrary parameters (p, q, ...) and that 'knot' is the interpolation algorithm viewpoint.

If so, what you have described seems to be:

          1 interpolates for        *
[2DCurve] --------------------------- [Spline]
    | 1               R1                  A
 R2 |                                     | R3
    | composed of                 +-------+------+
    | *                           |              |
 [Node] -----------------+     [XandY]        [PandQ]
 + x    1 corresponds to |        | 1            | 1
 + y                     | R4     |              | R6
    | 1                  |    R5  | interpolates | interpolates
    | associated with    |        | between      | between
 R7 |                    |   1    | *            | *
    |                    +---- [XYKnot]       [PQKnot]
    |                                            | 1
    | *                         R8               |
 [Parameter] ------------------------------------+
  + p        1 corresponds to
  + q

The Knot vectors are represented by the R5 and R6 relationships and the curve node vector is represented by the R2 relationship. By separating the Parameter values, one can add parameters by simply dynamically instantiating the R7 relationship (assuming an appropriate algorithm exists in a [Spline] subclass). [Note that [Spline] here is essentially the GoF Strategy pattern.]

Synchronization is maintained over the R4 and R8 relationships whenever there is a change.

Now for my dilemma: my current spline class supports a public member

I think this is the problem. Managing the relationships is really an instantiation problem for objects and relationships. Once that is done, the navigation will always "walk" the right vectors during the computations. IOW, I think the "add" capability is a collection class responsibility that should be managed by a factory rather than the curve or interpolation classes. That is, it is a structural definition that is orthogonal to the computational problem.

When a Curve is initially instantiated one needs to (a) instantiate a Curve, (b) instantiate the relevant Nodes and add them to the R5 collection class, (c) instantiate corresponding XYKnot objects and the R4/R5 relationships, (d) instantiate any relevant Parameter objects and add them to the R7 collection, and (e) instantiate the corresponding xxKnot objects and the relevant relationships (e.g., R6/R8).

Note that (d) and (e) can be done dynamically at run time; the processing is exactly the same as it they were "hard-wired" at startup. Also note that all this instantiation can be defined in external configuration data. So one could add or remove nodes and parameters to be interpolated or change algorithm assignments without touching the code. However, that assumes that an appropriate subclass of [Spline] exists that contains the right algorithm. To add a new algorithm one would still have to muck with the code.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Confusion about splitting classes to allow sharing of resources
    ... I have a working Spline ... >> Along with the splines for x and y, the Curve class also has one ... >> Adding new interpolation variables in subclasses of Curve will then ... instantiate the relevant Nodes and add them to the R5 ...
    (comp.object)
  • Re: Confusion about splitting classes to allow sharing of resources
    ... > selecting algorithms is a good job for patterns like Strategy. ... Spline classes, such as LinearSpline and CubicSpline, based on the same ... The higher-level class Curve should be able to select ... >> interpolation data gets regenerated. ...
    (comp.object)
  • Re: Confusion about splitting classes to allow sharing of resources
    ... Indeed one can imagine different interpolation schemes, like linear and cubic interpolation, using the same interface. ... I think where my thinking got flawed, is that I use spline objects to actually *store* the data that needs interpolation. ... Sorting out and selecting algorithms is a good job for patterns like Strategy. ... The exact shape of the function is determined by the values of x, y, p and q at the curve nodes, as well as the value of t defined at the curve nodes. ...
    (comp.object)
  • Re: Confusion about splitting classes to allow sharing of resources
    ... Then the Spline would ... actual interpolation to the algorithm de jour one set of points at a time. ... regeneration behavior since it is the only one that uses the data. ...
    (comp.object)
  • Re: Confusion about splitting classes to allow sharing of resources
    ... > both the algorithm and the data. ... Then the Spline would ... > between spline flavors are the interpolation algorithm, ... It's the responsibility of this 'somebody' I am still a bit confused ...
    (comp.object)