CMSC 202 Spring 2003
Project 2 Solution

The following solutions for CMSC 202 Project 2 -- Quadrilaterals -- is provided by your instructors. The basic solution is one you should be able to produce. The other solution is more advanced in that it addresses the issue of a "well formed" quadrilateral that was discussed on the project 2 discussion board.

If you have any questions about these solutions, email Mr. Frey or Mr. Raouf, or post them on the Project 2 discussion board.

Feel free to use either of these solutions as your starting point for project 3.

Source code for both solutions

Basic Solution

The basic solution consists of the files This solutions makes all the assumptions permitted by the project. In particular, it assumes that the quadrilateral is well formed and that the base is parallel to the x-axis.

Some things to note about the design and implmentation

  1. All input and output is performed in main()
    As mentioned in class many times, classes should be reusable and have no "awareness" of how they are being used. This means in particular that no user prompting is done inside the class. The mutators simply change the private data members.
  2. Along similar lines, note how main() only has access to the Points in the Quadrilateral through the Quadrilateral's accessors. Also note that the Quadrilateral must use the Point's accessors.
  3. With aggregation, there is a "layering" effect.
    main( ) communicates with the Quadrilateral which communicates with the Points. main()'s access to the Quadrilateral's private data is controlled by the Quadrilateral's public interface.
  4. Just because the Quadrilateral's accessors and mutators use references to Points does not guarantee or require that the Quadrilateral stores the corners in Point objects. It could very easily be the case that the Quadrilateral stores the corners' coordinates in eight separate integer data members.

Alternative Solution

This solution deals with the issue of a "well formed" Quadrilateral.

When a quadrilateral is first constructed, what coordindates do the corners have? Are they all set to (0, 0)? Do they form a unit square with the lower left corner at the origin?

When a mutator changes the coordinates of a corner, do the four corners still form a quadrilateral? Is the upper-right corner still in the upper right position relative to the corners?

What should methods like IsRectangle() or Area() return if the points don't really form a quadrilateral.

In the basic solution, we weren't concerned with these issues, because the project description promised us the user would input points that represented a well formed quadrilateral.

This solution does not make those assumptions. This solution keeps the "state" of the Quadrilateral (ie well-formed or not). The state is checked by those functions that care, and modified whenever something about the Quadrilateral (ie a corner) is changed.

In keeping with good OO design, all of these issues are dealt with inside the Quadrilateral class. The files Quad2.H and Quad2.C are a new implementation of the Quadrilateral class. Use these in place of Quadrilateral.H/C in the basic solution.