Associations in Object-Oriented Programming

1. CSCI 383 Object-Oriented Programming & Design Lecture 11 Martin van Bommel

2. Associations (review) • Anassociation is used to show how instances of two classes are related to each other • Associations have names and instances can have role names • One-to-one, many-to-one, many-to-many • Associations can have attributes CSCI 383 Lecture 11 M. van Bommel

3. Reflexive Associations • It is possible for an association to connect a class to itself CSCI 383 Lecture 11 M. van Bommel

4. Directionality in Associations • Associations are by default bi-directional • It is possible to limit the direction of an association by adding an arrow at one end • In a specification view this would indicate that a Day has a responsibilityto tell which notes it is associated with, but a Note has no corresponding ability to tell which day it is associated with • In an implementation view, one would indicate that Day contains pointer(s) to Note(s), but a Note would not point to any Day CSCI 383 Lecture 11 M. van Bommel

5. Generalization • Specializing a superclass into two or more subclasses. They must follow the isarule • Our idealization of inheritance is captured in a simple rule-of-thumb. Try forming the English sentences “An A is-a B ”. If it “sounds right” to your ear, then A can be made a subclass of B • A dog is-a mammal, and therefore a dog inherits from mammal • A car is-a engine sounds wrong, and therefore inheritance is not natural, but a car has-a engine CSCI 383 Lecture 11 M. van Bommel

6. Generalization (cont’d) • Represented using a small triangle pointing to the superclass • Thediscriminatoris a label that describes the criteria used in the specialization CSCI 383 Lecture 11 M. van Bommel

7. Generalization • Generalization captures similarities between several classes in a superclass. • Specialization refines and adds differences in subclasses CSCI 383 Lecture 11 M. van Bommel

8. Inheritance: Extension and Contraction • Because the behavior of a child class is strictly larger than the behavior of the parent, the child is an extension of the parent (larger) • Because the child can override behavior to make it fit a specialized situation, the child is a contraction of the parent (smaller) CSCI 383 Lecture 11 M. van Bommel

9. Avoiding Unnecessary Generalizations Inappropriate hierarchy of classes, which should be instances CSCI 383 Lecture 11 M. van Bommel

10. Handling Multiple Discriminators What about sharks? CSCI 383 Lecture 11 M. van Bommel

11. Handling Multiple Discriminators • Creating higher-level generalization may result in duplication of features • Another possible solution is multiple inheritance. • However, it adds too much complexity and is not supported by many OOP languages (e.g., Java, C++) The platypus, a difficult case for single inheritance Why? Egg-laying mammal CSCI 383 Lecture 11 M. van Bommel

12. Avoiding Having Instances Change Class • An instance should never need to change class • How to solve this problem? CSCI 383 Lecture 11 M. van Bommel

13. More Advanced Features: Aggregation • Aggregations are special associations that represent ‘part-whole’ relationships • The ‘whole’ side is often called the assembly or the aggregate • This symbol is a shorthand notation association named isPartOf CSCI 383 Lecture 11 M. van Bommel

14. More Advanced Features: Aggregation • Example: “A CPU is part of a computer” • Example: “A car has an engine and doors as its parts” CSCI 383 Lecture 11 M. van Bommel

15. When to Use an Aggregation • As a general rule, you can mark an association as an aggregation if the following are true • You can state that • the parts ‘are part of’ the aggregate • or the aggregate ‘is composed of’ the parts • When something owns or controls the aggregate, then they also own or control the parts CSCI 383 Lecture 11 M. van Bommel

16. When to Use Aggregation • Aggregation vs. attributes • Attributes describe properties of objects (e.g., speed, price, length) • Aggregation describe assemblies of objects • Aggregation vs. association • Is a company an aggregation over its employees or is it an association between its employees? CSCI 383 Lecture 11 M. van Bommel

17. Composition • A composition is a strong kind of aggregation • if the aggregate is destroyed, then the parts are destroyed as well • A one-to-one composition often corresponds to a complex attribute. Two alternatives for addresses (i.e., as an attribute or as a composition) CSCI 383 Lecture 11 M. van Bommel

18. Interfaces • An interface is a (abstract) class with no implementation • An interface is implemented (refined) by (different) classes • Example: A portable text editor displays its windows using a window interface that is implemented differently for Windows 95 and Mac OS CSCI 383 Lecture 11 M. van Bommel

19. Abstract Classes • An abstract class is a class without a (full) implementation • Some methods are deferred (i.e., they are not implemented) • The deferred methods are implemented by subclasses only • Example: The window move operation is implemented by using hide and show methods which are implemented by subclasses CSCI 383 Lecture 11 M. van Bommel

20. Example Class Diagram CSCI 383 Lecture 11 M. van Bommel

21. How to Use Class Diagrams • Class diagrams are the backbone of nearly all object-oriented methods. Especially they facilitate codegeneration • The trouble with class diagrams and their rich notation is that they are extremelydetailed and therefore can be confusing • Do not try to use all the notations available to you, if you do not have to • Don’t draw diagrams for everything; instead concentrate on the key areas CSCI 383 Lecture 11 M. van Bommel