12.3. The Java GUI API
11.3. Discovering Class Relationships
The common relationships among classes are: association , aggregation , composition , dependency , and inheritance .
11.3.1. Association
Association is a general binary relationship that describes an activity between two classes. For example, a student taking a course is an association between the Student class and the Course class, and a faculty member teaching a course is an association between the Faculty class and the Course class. These associations can be represented in UML graphical notations, as shown in Figure 11.2.
Figure 11.2. A student may take any number of courses, and a faculty member teaches at most three courses. A course may have from five to sixty students and is taught by only one faculty member.
An association is illustrated by a solid line between two classes with an optional label that describes the relationship. In Figure 11.2, the labels are Take and Teach . Each relationship may have an optional small black triangle that indicates the direction of the relationship. In Figure 11.2, the direction indicates that a student takes a course, as opposed to a course taking a student.
Each class involved in the relationship may have a role name that describes the role it plays in the relationship. In Figure 11.2, teacher is the role name for Faculty .
Each class involved in an association may specify a multiplicity . A multiplicity could be a number or an interval that specifies how many objects of the class are involved in the relationship. The character * means unlimited number of objects, and the interval m..n means that the number of objects should be between m and n , inclusive. In Figure 11.2, each student may take any number of courses, and each course must have at least five students and at most sixty students. Each course is taught by only one faculty member, and a faculty member may teach from zero to three courses per semester.
Association may exist between objects of the same class. For example, a person may have a supervisor. This is illustrated in Figure 11.3.
Figure 11.3. A person may have a supervisor.
In Java code, an association can be implemented using data fields and methods . The method in one class contains a parameter of the other class. For example, the relationships in Figure 11.2 may be implemented in the following classes:
Note
| | If you don't need to know the courses a student takes or a faculty member teaches, the data field courseList and the addCourse method in Student or Faculty can be omitted. |
11.3.2. Aggregation and Composition
Aggregation is a special form of association that represents an ownership relationship between two objects. Aggregation models has-a relationships. The owner object is called an aggregating object , and its class, an aggregating class . The subject object is called an aggregated object , and its class, an aggregated class . The association "a person has a supervisor" in Figure 11.3 is actually an aggregation.
An object may be owned by several other aggregating objects. If an object is exclusively owned by an aggregating object, the relationship between the object and its aggregating object is referred to as composition . For example, "a student has a name" is a composition relationship between the Student class and the Name class, whereas "a student has an address" is an aggregation relationship between the Student class and the Address class, since an address may be shared by several students. In UML, a filled diamond is attached to an aggregating class (e.g., Student ) to denote the composition relationship with an aggregated class (e.g., Name ), and an empty diamond is attached to an aggregating class (e.g., Student ) to denote the aggregation relationship with an aggregated class (e.g., Address ), as shown in Figure 11.4.
Figure 11.4. A student has a name and an address.
An aggregation relationship is usually represented as a data field in the aggregating class. For example, the relationship in Figure 11.4 can be represented as follows :
In the relationship "a person has a supervisor," as shown in Figure 11.3, a supervisor can be represented as a data field in the Person class, as follows:
public class Person { private Person supervisor; ... }
If a person has several supervisors, as shown in Figure 11.5, you may use an array or an ArrayList to store the supervisors.
Figure 11.5. A person may have several supervisors.
Note
| | Since aggregation and composition relationships are translated into the same class template, for simplicity, both are called composition. |
11.3.3. Dependency
A dependency describes a relationship between two classes where one (called client ) uses the other (called supplier ). In UML, draw a dashed line with an arrow from the client class to the supplier class. For example, the ArrayList class uses Object because you can add objects to an ArrayList . The relationship between ArrayList and Object can be described using dependency, as shown in Figure 11.6(a). The Calendar class uses Date because you can set a calendar with a specified Date object. The relationship between Calendar and Date can be described using dependency, as shown in Figure 11.6(b).
Figure 11.6. (a) ArrayList uses Object . (b) Calendar uses Date .
In Java code, a dependency can be implemented using a method in the client class. The method contains a parameter of the supplier class type. For example, the ArrayList class has the add(Object) method that adds an object to the ArrayList . The Calendar class has the setTime(Date) method that sets a new time in the calendar.
Note
| | Both association and dependency describe one class as depending on another. Association is stronger than dependency. In association, the state of the object changes when its associated object changes. In dependency, the client object and the supplier object are loosely coupled . The association relationship is implemented using data fields and methods. There is a strong connection between the two classes. The dependency relationship is implemented using methods. |
11.3.4. Inheritance
Inheritance models the is-a relationship between two classes. A strong is-a relationship describes a direct inheritance relationship between two classes. A weak is-a relationship describes that a class has certain properties. A strong is-a relationship can be represented using class inheritance. For example, the relationship "a faculty member is a person" (shown in Figure 11.7(a)) is a strong is-a relationship and can be represented using the class in Figure 11.7(b).
Figure 11.7. Faculty extends Person .
A weak is-a relationship can be represented using interfaces. For example, the weak is-a relationship "students are comparable based on their grades" (shown in Figure 11.8(a)) can be represented by implementing the Comparable interface, as shown in Figure 11.8(b).
Figure 11.8. Student extends Person and implements Comparable .
Note
| | Not all is-a relationships should be modeled using inheritance. For example, a square is a rectangle, but you should not declare a Square class to extend a Rectangle class, because there is nothing to extend (or supplement) from a rectangle to a square. For class A to extend class B , A should contain more detailed information than B . |
EAN: N/A
Pages: 503