########################################
#Written by David Tam, 1997. #
#davidkftam@netscape.net Copyright 1999#
########################################
David Tam
Assignment #2
Discussion of Design Decisions
==============================
A major design decision was that the primitives would hold the intersect
methods rather than have the vector class hold these. This decision allows for
better modularity because other types of primitives may be added without
affecting the program too much. In this way, the vector class does not have to
know anything about the primitives. They can use a client/server relationship
and ask the primitives if and where they are intersected. This design decision
should hopefully allow for polymorphism more easily too.
I decided to break up the duties of pixel rgb generation in terms of higher
level to lower level responsibilities, rather than designating it all to one
just one class. Duties were given to three main classes; Vscreen, PixelCenter,
and IntersectionPoint. The Vscreen class assembles each pixel rgb value and
gives it to the Outfile class for output to a file in a orderly fashion. The
PixelCenter class is invoked by Vscreen. PixelCenter adds up all of the terms
that make up colourrgb to make the final rgb value of the pixel. PixelCenter
gets each term by using a client/sever relationship with the IntersectionPoint
class. IntersectionPoint handles all of the different rays that are used in
calculations. This class creates and manages these ray classes and also does
the lower level computations. This design allows for future, more complex
ray-tracing methods to be added to the program. For instance, if a better
method is found for calculating the specular component, only the
IntersectionPoint class has to be updated. The rest of the program will remain
unchanged.
On the issue of classification, I decided to make Lightsource a subclass of
the Point class rather than a subclass of primitive. It's enclosed data
(variables) were more compatible with the point class.
The IntersectionPoint class is given a lot of co-ordination behaviour. It
has the duties of managing objects and classes because this is the point where
most classes meet and must interact and re-interact. In this class, I also
decided that it was best for it to have an aggregate relationship with all of
the different ray classes. I figured this should be related by value rather
than by reference because the ray classes only need to be created and destroyed
while IntersectionPoint is invoked. A client/server relationship is not used
either, because these ray objects do not need to exist outside of
IntersectionPoint.
(
geocities.com/siliconvalley/campus/9640/3rdYear) (
geocities.com/siliconvalley/campus/9640) (
geocities.com/siliconvalley/campus) (
geocities.com/siliconvalley)