Re: Confusion about splitting classes to allow sharing of resources

[snip]

> I agree with the flaw for a number of reasons. As you note, lots of
> different algorithms can be applied to the same data. Sorting out
and
> selecting algorithms is a good job for patterns like Strategy. That
> allows the selection of the algorithm (i.e., dynamically
instantiating
> the relationship) to be separated from the routine computations.
> Generally that selection will require an understanding of the context

> that is beyond what the individual objects involved in a specific
> collaboration need to know about (i.e., they have there own problems
to
> resolve).

That should be easy enough to do by having a hierarchy of concrete
Spline classes, such as LinearSpline and CubicSpline, based on the same
Spline interface. The higher-level class Curve should be able to select
which to use for a given implementation.

> Separating the data also allows one to apply parametric polymorphism.

> One encodes more generic algorithms and allows detailed problem
> differences to be described in data. That, in turn, allows the
problem
> structure to be define in external configuration data rather than
being
> "hard-wired" in the code. Separating the data also allows one to
> capture the details of the problem in static structures. For
example,
> the number of knots and function values can vary from one problem to
the
> next while the algorithms remain the same (i.e., they "walk" the data

> collections in exactly the same way).
>
> > Whenever some of the data is changed, the spline object sets a flag
so
> > that when next time interpolation is performed, the
'behind-the-scenes'
> > interpolation data gets regenerated. What you are telling me here,
if I
> > understand correctly, is I should think of spline as an algorithm,
> > rather than as an object. Probably my data to be interpolated
should
> > then also be stored outside of the spline instance. Is that right?
>
> Maybe. B-) I'm not advocating functions as first class objects so
one
> still has objects for the algorithms a la the Strategy pattern. What
I
> am advocating is separating the concerns and encapsulating them in
> multiple objects. Then use the relationship structure instantiation
to
> define the specific problem. So in that sense your conclusion is
> correct; delegate the data responsibilities elsewhere and isolate the

> algorithms that may be substituted for processing the data.

Fact remains that the Spline may need to store state data for the
interpolation. A cubic spline, for instance, needs to store a vector of
the same length of the two input vectors - I usually refer to that as
the interpolation info. If the contents of any of these change, the
info becomes invalid and will need to be regenerated before any next
interpolation can be performed. You are spealing about
responsibilities. In the current situation, the spline itself is
responsible of keeping an eye out for changes in the data. From the
viewpoint of a user of the Spline class that seemed quite convenient to
me. But decoupling the data and the interpolation calculation seems to
imply that responsibility does not belong there. But this seems
counterintuitive to me - my intuition tells me to hide as much of that
sort of details away inside a class interface, so the users of the
class don't have to worry about whether or not the spline is valid or
not - the Spline object takes care of that itself. Where is the way out
of this apparent contradiction?

>
> >
> > I think the schema can be a little simplified in my case, since
both
> > the position (x,y) as the parameters p and q are modelled as a
> > parametric function of a single parameter t. 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. This
> > vector t[i] is what I refer to as the knot vector and is what is
used
> > to build the splines. So there is only one knot vector, even though
> > each variable can have it's own type of interpolation.
>
> OK. I inferred you were looking for something more versatile where
one
> could add other properties besides p and q in a fairly arbitrary
manner.
> If not, you only need one data holder class for the curve points.
>

The number of properties will not vary at runtime, only by subclassing
a Curve, so yes, I think one data holder should be sufficient.

> > As for the adding of nodes and knots, you're saying that should be
> > handled by whatever class wants to instantiate a Curve or a Spline,
> > right? Especially for the splines that makes much more sense if I
see
> > the spline class as an algorithm on outside data, not as an object
> > holding data. So I should write a SplineFactory class, and a
> > CurveFactory class, to provide that sort of facilities, correct? I
> > think I'll read up on factory classes a bit then, figure out how
best
> > to implement them.
>
> Yes, pretty much. I think the problem is complicated enough to
warrant
> separating the concerns of constructing the overall structure into a
> dedicated object(s). This is especially true if you use data holders

> and relationship collection classes for your [i] data. That object
can
> understand and encapsulate the rules for properly instantiating the
> relationships.
>
> I am not sure you need a bunch of factory objects (e.g., one for each

> class), though. It seems like the structure is pretty fixed for a
given
> curve. In that case it is pretty much just a succession of
constructor
> calls. IOW, it is complicated enough to encapsulate in a dedicated
> object but not so complicated that it needs to be delegated among
> multiple objects. The main decision seems to be determining the
right
> algorithms to use given the Curve type. If that is not too
complicated,
> it might be easier to jam it all in a single factory's method.
>
> [You may not need the polymorphism that the GoF construction patterns

> provide, though; you may just need a "hard-wired" variation on the
> concreteFactory object. The GoF patterns are all geared to dealing
with
> a situation where one needs to select the right factory based on some

> dynamic context. You pretty much know exactly what needs to be
> instantiated as soon as you get a particular Curve in hand.]

Yeah, a single CurveBuilder class would probably suffice here, that
might have a few functions to build particular types of curves, like
spheres. I wonder though, where does reading a curve from a file
belong: in the Curve class, or in the CurveBuilder factory?

>
> *************
> 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

The longer I think about this stuff, the more I see room for
improvement. My curves represent dynamic boundaries of a flow domain,
and the parameters p and q are more properties of the boundary than of
a curve, and also dynamic. So p and q should move into a Boundary class
(I hadn't mentioned it in my orignal post, didn't want to make it -too-
complicated ;)). I'm still trying to decide whether or not a Boundary
Is-A Curve, or Has-A Curve (or Has-A Shape, with Curve a Kind-Of
Shape), for instance. Since delegating is usually preferred over
inheritance, I am arching towards the latter. In that case, I would
like Curves to support external knot vectors too - I need to be able to
update the curve shape dynamics quickly, so I don't want unnecessary
copying and such. It seems I can move design ideas around like this for
ever - I guess it's a sign my design is not yet fully matured ;) It
even makes me wonder a bit whether I'm improving my design, or only
complicating it... Oh well, all part of the fun I suppose :) Thanks
again for your elaborate explanations,

regards Mark

.

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
    ... I have a working Spline class that does cubic spline interpolation of function values fthat are defined at knot positions t. ... Along with the splines for x and y, the Curve class also has one for any other values that need to be interpolated along the curve. ... 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. ... When a Curve is initially instantiated one needs to instantiate a Curve, instantiate the relevant Nodes and add them to the R5 collection class, instantiate corresponding XYKnot objects and the R4/R5 relationships, instantiate any relevant Parameter objects and add them to the R7 collection, and instantiate the corresponding ...
    (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: Revolve 3D curve?
    ... Hardly surprising, for the "2 sketch" sweep, that it conforms exactly. ... spline, being the starting profile for the sweep, forms a boundary of the ... I would expect that divergence would not be ... > the 3D curve. ...
    (comp.cad.solidworks)
  • Re: B-spline sampling?
    ... To sample the spline, and that works well. ... neighboring spheres, so they look like pearls on a string. ... My curve is the type, where you have a knot and a mirroed tangent vector ... if you have an arclength parameterization ...
    (comp.graphics.algorithms)