What makes for good OOA/OOD/OOP?

Object-Oriented Analysis

• It's general, and thus reusable.
• 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.
• Good hierarchy is always linked by IsA relationships.
• Attributes and services should be factored out as high in the hierarchy as possible.
• It should be easy to add on to, and thus reusable.
• There should be little or no redundancy.
• Again, objects are NOUNS.

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 report 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

• NEVER change a reused class! Use subclasses.