I’m writing a library to allow users to generate 3D models programatically.
- User writes code (e.g.
Square(4)) - User views preview of 3D model (with built in visualizer)
- User can “print” the model to a
.objfile that can be read by other 3D modeling programs and visualizers
What is a good way to architect the data objects and the above functionality?
Lets assume a Square object subclasses a Polygon class.
A Polygon would have
- vertices
- a face
- a transformation/translation
Eventually, I need to be able to print this polygon to the screen. Some part of my program will need to know how render it using a graphics library that I will use. However I don’t want to add this functionality as part of the Polygon class because I would like the Polygon class to only have to worry about pure geometric considerations, not details of graphics libraries. So, I could just create a Renderer object that can take Polygons and Circles and Curves and inspect them and then decide how to display them, but that didn’t seem very Object Oriented.
So to summarize, I want to have
- a bunch of different types of geometric objects (
Polygons,Circles,Curves, etc) - a few different ways to “print” the objects (display to screen, write to file, etc)
And I’m not sure where to put all of this functionality so that it is well encapsulated, easy to maintain, and extensible.
4
Visitor Pattern
Comedically, and with good fortune, I found the above Wikipedia article that precisely describes my situation (what are the odds?).
Consider the design of a 2D CAD system. At its core there are several types to represent basic geometric shapes like circles, lines and arcs…
one could apply the Visitor pattern. The Visitor pattern encodes a logical operation on the whole hierarchy into a single class containing one method per type.