Class Design & Inheritance

Objectives

In this laboratory, you will:

  • distinguish between good and bad program designs
  • distinguish between good and bad designs involving inheritance
  • understand the Liskov substitution principle and how it relates to the specification of preconditions and postconditions in overridden methods
  • design UML class diagrams

Lab Overview

Before you start your lab you should do the two pre-lab tasks.  The first task is to study a given description for a problem and try to identify the classes required for its solution.  The second task is to review your notes about inheritance.

The rest of the lab is divided into three parts:  

  • In the first part of the lab, you will work in groups to find out the mistakes in several class designs for a given problem.
  • In the second part your group will look at various examples of inheritance and critique them. 
  • In the final part, your group will design the solution to a small problem, and then you will critique another group's design for that same problem.

 


Pre-lab Exercises

a. Identifying Classes from a system description

It is often difficult to identify the appropriate classes to use for solving a problem, given the general problem descriptions. This is probably the most difficult part of object-oriented modeling. This lab will help you to understand what makes a class design good, and what makes another one bad.

When determining what concept a class should represent, and therefore what features it should have, you should keep the following in mind:

  • Classes represent entities rather than actions. In many cases finding classes can be as simple as looking for nouns in a sentence.
  • Actions that affect these nouns could be the methods for the corresponding classes.

Therefore, when examining a problem specification, you can start by picking out the nouns and the verbs. The nouns can be considered candidate classes or member variables, and the verbs can be considered candidate methods. The tricky part lies in determining which candidate classes and methods are necessary for solving the problem, and which ones aren't. There is no easy way to pick classes out of a description, but with enough practice and experience this should become easier.

Before you come to this lab, read the system description below and identify all of the classes you believe will be required to implement it. You will use this problem in the first part of the lab.

         Video Store Problem
Mr. Brickbuster, a local video store owner, has commissioned you to design a software package to organize and manage the rentals of his videos. His store contains hundreds of movies that fall into one of three categories: comedy, drama and action. There are some movies of which the store owns more than one copy, and more copies can also be purchased if demand warrants it. Mr. Brickbuster would like to have a way of keeping track of both the number of copies of each movie that is available for rent, as well as the name of the customers who are currently renting each unavailable video. The video store frequently adds new customers and sometimes needs to update customer's information, such as their phone number or home address. One of the most important features that Mr. Brickbuster wishes to see is an easy to use program that will allow his tellers to quickly manage all of this information using a graphical user interface.

b. Inheritance Review

Review your CPSC 111 and 211 notes about inheritance. If you would like an additional refresher about inheritance, one is available here.


In-lab Exercises

Your TA will ask you to form groups of 2or 3 people to work on all three parts of this lab.

Part 1. Design Comparisons

In this part your group will compare the following program designs which are related to the Video Store problem you studied before the lab.  Each diagram represents some part of the design of the system, but may not be the complete design. In each case try to determine which of the two given designs is essentially better, and in which situations each design might be preferred over the other. Remember that there are usually no definite right or wrong answers. This exercise will help you recognize that there are sometimes different, equally valid ways to solve one problem.

1.

vs.

2.

vs.

 

3.

vs.

Part 2. Inheritance Design Comparisons

In this part, each group has to determine the good and bad points of each of the following design decisions. If you think the design solution is poor, suggest improvements or changes to make it better.

1. A programmer is designing a system that involves the manipulation of shapes. She has already created the class Ellipse which has the function setSize(x,y) defined. She wishes to create a Circle class where a circle is an ellipse with equal x and y. Would it be a good design decision for her to create a Circle class by subclassing Ellipse?

2. A programmer is designing a system to simulate the picking of fruit. He has already written a class for Bag-of-Fruit which is to be used to collect fruit. This class has a member function addItem(Fruit newItem). He now wishes to create a subclass of Bag-of-Fruit called Bag-of-Apples which is a bag which will only allow the addition of Apples to the bag. Is this a good design decision?

3. A programmer wishes to design a video game that uses the taxonomy of animals. What factors do you think will influence her decision to either use an interface to specify the behaviour of the animals or use an abstract class as a base class for the concrete animal classes?

4. A programmer is using a game framework to design a new video game. The framework contains a Trajectory class containing the following attributes and methods::

 
private double dx = 0;
private double dy = 0;
public double getDx()
{
   return dx;
}
public double getDy()
{
   return dy;
}
/**
 * Method to set the velocity of the trajectory.
 * @pre none
 * @post getDx() = deltaX, getDy() = deltaY
 */
void setVelocity( double deltaX, double deltaY )
{
   this.dx = deltaX;
   this.dy = deltaY;
}

The programmer wants to add "sticky" pieces to the game that cannot move backwards and that are slowed down due to friction with the ground. The programmer therefore decides to implement a StickyTrajectory class that is a subclass of Trajectory. The setVelocity method is overridden as follows:

/**
 * Method to set the velocity of the trajectory.  The supplied velocity is modified to account for
 * friction using a simple (and physically unrealistic!) square-root model.

 * @pre deltaX >= 0 AND deltaY >= 0
 * @post getDx() = sqrt( deltaX ), getDx() = sqrt( deltaY )
 */
void setVelocity( double deltaX, double deltaY )
{
   this.dx = Math.sqrt( deltaX );
   this.dy = Math.sqrt( deltaY );
} 

Comment on this design decision.

 

Part 3. Critiquing class designs for the students' timetable problem

The main purpose of this section is to help you understand the basics of good software design. You will look at someone else's design, and try to understand what they did right, and what they did wrong.

  1. Each group should read the following scenario and come up with the class diagram for it. Your design does not need to be fancy - you should not have more than half a dozen classes in all. Once you are confident that your design is fairly stable, write it down.

             Students' timetables
    You have been asked to implement a small part of the university system that keeps track of students and their timetables. The design must conform to the following restrictions:
    • First, each student has only one timetable. Conversely, a timetable can be associated with more than one student, since it is basically a collection of sections.
    • Courses, in turn, are composed of 1 or more different sections, offered at different times and locations. Thus, there are potentially two or more people enrolled in the university who attend all the same sections for the same courses (like a Standard timetable), and thus would all share the same timetable.
    • Each section can also be associated with any number of timetables. If it is not associated with any timetable at all, that means there are no students enrolled in it.
    • Finally, there are also advisors whose function it is to help students with course planning, etc. Each student is assigned to one particular advisor, but an advisor is responsible for many students.
  2. After all groups have submitted their design, the TA will distribute the designs back to the class, so that each group ends up with another group's design. The purpose of this exercise is to critique the other group's design. The TA will go over the solution to the design problem at the end of the class, but this exercise will get you to apply what you know about specific design principles to critique another design. Examine the design you have been given and write down where you think it should be different and why.
  3. After everyone has submitted their designs and critiques, the TA will go over the solution to the design problem. Compare the design you have submitted to the one presented, and see if you did anything wrong. If there is time, the TA will go over some of the critiques submitted, and show you examples of good and bad critiques that were submitted, and explain why they are good or bad.