CS 4448 - Fall 1998
Object-Oriented Programming and Design
Homework #5
Due on Monday, October 5 at the start of class.
You must:
- Hand in your HW#4 and the other persons HW#4 that you were given
in class.
- You must write comments on each design. Take into account that
the design should have been totally unambiguous. This means that there
are no places were you need to make design decisions. Everything
missing should be coding details. You may make your comments on
separate paper or on the HW#4 if you use a distinct ink color.
- Make a new design. This may be your design or the other persons
design from HW#4 for a hand full of you. Most of you will need to
start over but may choose to use HW#4 as a starting point. The design
must include amazing details including:
- Inheritance hierarchy
- The class that contains/has-a instance variable. So, if the
variable living is found in MaterialObject then you need to show that
in your design.
- Show were methods are created. The method alive maybe found in
the MaterialObject class. Describe what the method actual does in
detail. So a constructor for dog needs to say what the passed in
parameters do and what other things might be happening. Example,
speak is being set to "Whof, Whoph".
- The previous example with dog might also show where a method is
overridden by a child. The old constructor, if it had the same
parameters, was overwritten by the child. New functionality was
added and then the parent was called. Your design should say what is
happening and that the child does ... and then has the parent do its
thing. You need to specify how the child calls the parents method but
you don't need the parent detail in the child since the parent has
that information. If you want to remove the some constructor or method
that comes from the parent, an example is the constructor with no
parameters. You can do this by having the child override that method and
put it in private or in SmallTalk by having the child call the error:
or shouldNotImplement method, etc....
- Show has-a relationships, example: BeakerHolder has Beakers.
- Show uses relationships, you find this one.
You can decide how much detail to put in the diagram and put the rest
in some other format on another page. Ex: class name then the list
of methods and instance variable with the detail that you left out of
your diagram.
- Your may no longer hard code Mass into Molecule. You must find some way
using Beaker, BeakerHolder, and Element to figure out the mass.
- Make a new category in SmallTalk for you system. How about "HW#5"
- Implement your design in SmallTalk.
- Print out your SmallTalk code and hand it in.
- Print out some tests showing what your system can do and hand it in.
- Tar and then Gzip your work into one file. Make sure what you
submit is correct. Email the code to yourself
first. Make sure you get one file that you sent. Untar and ungzip the
file. Now start Squeak and make sure it is not starting with your old
state stored. File-in your assignment and try all your tests. If all
goes well then...
- Email your SmallTalk code to the TA. Remember it must be tarred
and g-zipped. DO NOT send him more then one file, as it will not be
accepted.
Keep in mind how your design effected your implementation. Also, see
if you needed to modify your design when you found errors upon
implementation. We will talk about this in class but you don't have to
write that one sentence on the homework
.
Requirements
Consider future enhancements and see the big
picture. Anticipate future needs that one might have on your design.
It should be noted that no design is ever final, we always go back at
some later date and make modifications. We will do this at the start
of the next class so anticipating future design needs.
Why fixed names?
The class names and method names are fixed since someone else wants
your classes for use by their classes. This hypothetical, "They",
have created their own stubs for some of the code and will be
replacing them with your code.
This time the syntax I am using is SmallTalk.
The knowledge you gain from your design and implementation in
SmallTalk with transfer. Result: it will be relatively easy to
have your design work with C++ for the following assignment.
Classes and class methods that need to work for instantiation
- Dog weight: name: kind:
- Cat weight: name: kind:
- Sprinter weight: name:
- Molecule name: 'Water' (Comment - The string Water is just one example)
- Beaker name: 'MagnesiumChloride' (Comment - Just an example name)
- Magnesium new
- Chlorine new
- Hydrogen new
- Krypton new
- Pine weight: height:
- Plant new
- Animal new
- BeakerHolder new (This class can be considered a stand that hold
infinite Beakers)
- CouchPotato weight: name: (Comment - For those from different
cultures, this is a person who watches TV all day and does not move
unless they need a beer or to go to the bathroom)
- Student weight: name:
Some additional classes that might help you design include: Mammal,
Quadraped, Biped, Human, Tree, and last but not least a MaterialObject.
Note: name may not be set after instantiation. Every object for our
design, comes into existence with a name and never changes
it.
Instances and minimum instance methods
- aDog speak; name; topSpeed; hasLiveYoung; spontaneousMovement
- aCat speak;legs
- aSprinter topSpeed;
- aStudent speak; legs
- aMolecule mass; name; chemicalSymbol
- aHydrogen mass; chemicalSymbol
- aKrypton name; family
- aPine deciduous;height
- aPlant alive
- aBeakerHolder find: ; hold: ; giveBack: (Comment: think of
giveBack as unhold, add and remove might give you ideas of what hold:
and giveback: do)
- anAnimal hasSex (Comment: this method is not a social commentary
but a question about gender :)
- aBeaker numberOfAtoms; name; add: ; remove: (Comment: these methods let you add and
remove atoms to the beaker)
- aCouchPotato speak; topSpeed; spontaneousMovement (Comment: See
Animal vs. Plant in the dictionary. I agree see your question and I
don't know the answer either. Is a CouchPotato Animal or Vegetable or
Mineral, but certainly not the Model of a Modern Major General)
Adam Jonathan Griff,
computer@griffmonster.com
Copyright © University of Colorado. All rights reserved.
Revised: September 29, 1998