Martin, Thank you for answering my question.
You wrote: "But the current approach seems just fine to me - it's very clear in the code what is being done." I didn't mean to question the implementation. (I've learned the hard way that things in JUMP and JTS were usually done for a good reason or good reasons.) I was just curious about the design, as it was something I hoped to adapt to my own code if the opportunity presented itself. The Sunburned Surveyor On Jan 7, 2008 11:56 AM, Martin Davis <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ jts-devel mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jts-devel
