1. The Relationships Between Classes & Objects Presented by Tim Sweeney

2. How are classes and objects organized best? Four basic relationships in the OO paradigm Uses Containment (implies a uses relationship as well) Inheritance Association What are the heuristics governing how to sort desired behavior into these relationships, and how best to implement them?

3. What are our goals for these rules? The general goals of object oriented programming Ease of understanding Potential for reuse of code Anticipating needs and fulfilling them in the design stage

4. Overview of heuristics Uses How do we implement the uses relationship? When can we turn use into containment? Collaboration With how many classes and in how many ways should an object collaborate with others?

5. Overview of heuristics Containment When is containment the right relationship? How many objects should be contained? What should an object know about its container? Semantic Constraints At what level should we impose our semantic constrains on objects?

6. Uses Can an object send a message directly to another class? That means a uses relationship is needed. How do we know where to send the message? #1 implementation: Containment (ATM -> Cash Dispenser) We’ll come back to this later.

7. Uses #2: Parameter passing #2a: Global data as parameter #3: Use of a third party class #4: Built on need #5: Defined during construction

8. Complexity of uses relationship # of classes X communicates with # of methods X uses to communicate # of messages sent by X’s methods We can see this illustrated in a class diagram – how many classes does one class communicate with, and how many messages are sent?

9. Minimization of collaboration Minimize the # of classes collaborated with Much larger design issue than methods or messages Where possible, use information hiding and containment to reduce the number of classes “Can I replace this group of classes with one class containing the group, thereby reducing the number of collaborations?”

10. Minimization of collaboration Minimize the number of messages sent between a class and a collaborator. Minimize the number of different messages sent. Minimize fanout (the product of the messages defined by the class and the messages they send). Balance class use with message use. Class use is harder to justify.

11. Containment When abstraction is possible, it should be used (this minimizes the number of classes that need to be communicated with). Containment is powerful for keeping uses relationships from getting out of hand.

12. Heuristics of containment Containment should always imply use. (If a containing class does not communicate with its contents, why does it have them?) exception: container classes (vector, etc.) Methods of a class should be using most of the data members most of the time. (Otherwise the class is too abstract and should be split.)

13. Heuristics of containment Keep the number of contained classes small. (Should fit in short-term memory or so). This is related to our earlier uses heuristic. Distribute the containment hierarchy narrowly and deeply. (Mostly for reuse.)

14. Attributes vs. contained classes Fundamental data without behaviors are not the same as contained classes. Don’t create classes simply to contain attributes.

15. More hierarchy heuristics Two balancing principles: a class should be oblivious to its container, and also oblivious to the objects it shares that container with. Oblivious to container: an AlarmClock in a BedRoom should be the same as an AlarmClock in a TimeLockSafe.

16. Hierarchy Oblivious to objects in same container: The container should mediate communication between its contained objects as opposed to causing uses relationships between each of them. These two principles can contradict each other—but only in certain cases.

17. Containment versus uses Student/Alarm clock Classroom/students Automobile/engine “If I remove the contained object, is the behavior of the containing class modified?” Yes == strong containment, or composition No == weak containment

18. Semantic constraints Best to keep constraints in the class definition. When not possible, put them in the behavior (usually constructor). Place the constraint as far down the containment hierarchy as possible.

19. Semantic information As opposed to capturing the information in the construction, we can check the state of created objects for validity when they are used. If the information is volatile, place in a third- party object. If the information is stable, place that information in the classes involved.