Not if these are "named design patterns", but I would list some of the
patterns motivating this design as: Modularity, Separation of Concerns,
Adherence to Published APIs...
One pattern which might be closest to describing this Design is the
Decorator pattern. Don't forget, there is LocationIndexedLineString as
well as LengthIndexedLineString. It would be fairly ugly IMHO to try
and push *both* of these concepts into the base LineString class.
If Java objects were "open" (a la Ruby or Javascript) then I suppose you
might consider simply adding this methods to the base LineString class
on-the-fly as needed. But the current approach seems just fine to me -
it's very clear in the code what is being done.
Another reason for separating these from LineString is that they both
potentially have state information, which is not required for most uses
of LineString.
Sunburned Surveyor wrote:
I hope this isn't a completely illogical question.
I was looking at the Javadoc for the LengthInexedLine class when a
question came to mind. It seems like all the functionality of a length
indexed line could have been included in the original LineString
class. I know there was obviously a reason to separate this
functionality into a separate class (simplicity perhaps) but I am
curious about a couple of things.
Is this an example of a design pattern? It seems like the basic
underlying design evident in the LenghtIndexedLine class could be
described as follows:
Functionality that could be included in the base class is moved to a
supporting class. The supporting class then accepts an instance of the
base class in its constructor or as a property and provides the
functionality moved from the base class for the instance.
I did some reading about different design patterns in Java to see if
there was one that applied to this situation. I thought maybe it was a
case of the Facade pattern in use, but after reading about the Facade
pattern I've changed my mind.
It there a "named" design pattern for the design evident in the
LengthIndexedLine class? Is there a good rule of thumb for deciding
when you would move behavior that could be included in a base class to
a supporting class that provides the functionality for an instance of
the base class?
Thanks for any information.
Landon
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
