![]() |
|
||||||||||||||||||
ObjectivesIn this laboratory, you will:
Lab OverviewBefore 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:
Pre-lab Exercisesa. Identifying Classes from a system descriptionIt 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:
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.
b. Inheritance ReviewReview your CPSC 111 and 211 notes about inheritance. If you would like an additional refresher about inheritance, one is available here. In-lab ExercisesYour TA will ask you to form groups of 2or 3 people to work on all three parts of this lab. Part 1. Design ComparisonsIn 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.
2.
3.
Part 2. Inheritance Design ComparisonsIn 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 problemThe 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.
|
|||||||||||||||||||
©University of British Columbia | Last updated:
September 27, 2007 19:03 |