Topical Information

This lab will help you practice with [run-time] polymorphism.

Program Information

Your company wants to branch out into the graphics market with a drawing program. But none of you has ever programmed graphics before. To prove yourselves to the company, you decide to write a proof-of-concept application to show that you can overcome all of the processing headaches.

You create an inheritance hierarchy like this:

                              Shape
                                |
            --------------------------------------------------
            |                   |                            |
           1D                  2D                           3D
            |                   |                            |
        ----------         -------------            -------------------
        |        |         |           |            |        |        |
       Line    Curve     Circle    Rectangle      Sphere    Cube    Cone

Each level adds either new methods -- new ways to achieve a behavior -- new attributes, or a simple abstraction to gather things more logically together. Your team leader (JasonJ) suggests that a basic Shape should know it's name and a Point. OneD, TwoD, and ThreeD might simply be for logical abstraction. Each other class would add enough data members to draw itself (a second Point for a Line, two [or more] other Points for a Curve, a radius for a Circle, either a second Point or length and width for a Rectangle, etc.).

As to behaviors (methods), all Shapes should know how to draw themselves. Of course, this being merely a proof-of-concept app -- and you not being able to do graphics with portable C++ -- you'll just have to skip that. You'll also need a Print method so the Shape can print its name and all pertinent data. For ease of use, you should also create any methods/operators you think might prove useful in the full application. But for speed of development, we'll leave them out here. (And, yes, the Print method will be useful even in a final application -- for debug printing ...to a file perhaps?)

You decide on a menu-driven app which allows the user to select a shape from a series of sub-menus (for now these are most easily aligned with the hierarchy). When they've chosen a Shape, create it (perhaps dynamically?), and add it to a container for later processing.

Other options from the main menu will be to print a list of all current Shapes (print their names), print all information about the current Shapes (print all their data), and remove a Shape from the list.

Thought Provoking Questions

  1. How many libraries did you create for your hierarchy? Do all of them have both interface and implementation files?
  2. How can you store information about so many different classes in a single container?
  3. What does that new keyword virtual have to do with any of this?
  4. Will you ever need/want to create an object of type Shape, OneD, TwoD, or ThreeD? How can you assure that this won't happen?
  5. What other methods/operators might prove useful in an application for drawing shapes? What if the application were more of a computer-aided instruction in geometry? Is there a need to limit your classes? (Note: You don't have to implement these, I'm just looking for descriptive responses.)
  6. What kind of container should you use to store the Shapes: dynamic array, static array, templated dynamic Array class, vector, ...? Since this lab has nothing to do with array management, what would be the most appropriate/easiest choice? (After all, you have nothing more to learn about container management...for now.)

This assignment is (Level 4).

Options