Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Criteria for Good OOA/D
See also http://www.gvu.gatech.edu/edtech/BOOST/designmap.html, the Design Road Map.
What makes for good OOA/OOD/OOP?
The following are the criteria that I've collected from class discussions as defining good object-oriented analysis and object-oriented design (and some good object-oriented programming).
Advice From the TA's:
Object-Oriented Analysis
- Everything is general when it can be, aiding reuse.
- Information access is enough. Objects that don't need information can't get to it. Objects that do need information can get to it (i.e., either they have it, or they have an instance variable that points to an object that has it.)
- Responsibility, control, and communication is distributed. One object doesn't do everything. Makes it easier to reuse, easier to develop and manage.
- Minimize assumptions of language or system. Try to describe the world, not a program.
- Define objects not functions or managers. Objects are nouns.
- Don't include things you don't need, even if it is part of the real world. Sure, everything is made up of molecules, but you probably don't need a molecules class.
- Most class hierarchies have IsA relationships.
- Attributes and services should be factored out as high in the hierarchy as possible.
- The changes you expect are most likely, are easy to add in the future.
- There should be little or no redundancy.
Object-Oriented Design
- Implementable. You can see how you'd write code from here.
- Complete. It's obvious that the OOA is right because everything you need to do is (1) covered in the OOD and (2) matches the OOA.
- Removes unnecessary middlemen. If A needs to reach B, but can only do it through C...think about allowing A to reach B directly.
TAs in the past have reported that some students just repeated the OOA in the OOD. For example, one might have defined a class named TempSensor that has a part-of relationship with a Refrigerator and has an attribute named DesiredTemp. In the OOD, we're seeing the script "I am a TempSensor. I know my DesiredTemp. I am part of a Refrigerator." Period. That's not the idea. The OOD is where you ALSO spell out what the TempSensor does and HOW it does it. Below is an example, with my notes in parentheses about what you should be thinking about when you're writing these out:
"I am a TempSensor. I know how to alert the Refrigerator when to turn on. (Which implies that I'd better have an instance variable for my Refrigerator.) When I get a tick message (Which implies that something is going to send the Tick message. Who? How do they track those of us who care about ticks?), I compare the current temperature (maybe there's a message which reads the device?) to the DesiredTemp, and if it's out of range (where is the acceptable range stored?), I send a message to the Refrigerator. (What message? Refrigerators better know how to respond to that message.)"
The idea is that the OOD is where you patch the pieces together, where you make sure that messages are caught, important information is known at the right places, that all the important services are accounted for.
Object-Oriented Programming
- Sprinkle useful comments around the system. Pretty much every class should have a comment.
- Choose names and categories so that they are informative. Every brain cycle you use trying to figure out what some variable means, or trying to find a related group of methods, could have spent doing something productive.
Links to this Page