Class Relationships

1. Class Relationships

2. Class Relationships • Chapter 12.4 in your textbook • Defines how classes relate to each other • How classes connect to each other • How classes communicate with each other • How classes work together Wendi Jollymore, ACES

3. Class Relationships • Association • Aggregation / Composition • Dependency • Inheritance Wendi Jollymore, ACES

4. Association • Defines the activity that takes place between two classes • Example: • Student, Course, Faculty • A student takes a course • A faculty member teaches one or more courses • See Figure 12.3 & 12.4, page 396 • Implemented in code using fields and methods • See top of page 397 Wendi Jollymore, ACES

5. Aggregation / Composition • Defines ownership between classes • One class contains or owns parts • A “has a” relationship • Examples: • A CD object can contain Song objects • A Student object owns a Name object • See Figure 12.5, page 397 • Implemented using data members • See bottom of page 397 Wendi Jollymore, ACES

6. Aggregation / Composition • Aggregation: • The aggregated object(s) (parts) can exist without the aggregating object/class (container/owner) • The aggregated object(s) can be owned or contained within multiple aggregating objects/classes • Example: • An Address object can be owned by multiple Student objects • A Song object can be on many different CD objects Wendi Jollymore, ACES

7. Aggregation / Composition • Composition: • The aggregated object generally doesn’t exist without its aggregating object/class • The aggregated object is exclusive to the aggregating object/class • Example: • In a program that uses a functional Car object, the Engine can’t exist without the Car object, and that Engine is only used by that Car object • A Name object (first, last, initial) is exclusive to one specific student, and wouldn’t exist on the system unless there was a Student object that owned that specific name. Wendi Jollymore, ACES

8. Dependency • Defines classes that “use” each other or each other’s services • A “uses” relationship • The client class/object uses the supplier class/object • Example: • The ArrayList class uses the Object class • See Fig 12.7, page 398 • Implemented in client class using methods • Contain a param of the supplier class type Wendi Jollymore, ACES

9. Coupling • Coupling defines the amount of dependency between classes • Loose coupling • Less dependency between classes • Changes in one class don’t affect the other classes • Tight coupling • More dependency between classes • Changes in one class greatly affect how the other classes function Wendi Jollymore, ACES

10. Coupling • Association, Aggregation, Composition, and Dependency • Include some degree of dependency • Include some degree of coupling • See 12.4.4, page 399 Loose Coupling Tight Coupling Dependency Association Aggregation Composition Wendi Jollymore, ACES

11. Inheritance • Defines classes that have common characteristics (attributes, functionality) • An “is-a” relationship • Strong inheritance uses classes • Weak inheritance uses interfaces • Examples: • A Full-Time Employee is an Employee; a Salary Employee is an Employee • A Car is a Vehicle; a bike is a Vehicle • A Cylinder is a Shape with 3d properties, a Square is a Shape • See figure 12.9, page 399 Wendi Jollymore, ACES

12. Exercise • Do Question 12.2 on page 416 • See page 401 for the last one • Company/Employee: Aggregation • Course/Faculty: Association • Student/Person: Inheritance • House/Window: Composition • Account/Savings Account: Inheritance • JOptionpane/String: Dependency • Loan/Date: Composition Wendi Jollymore, ACES

13. UML Notation • Notation for Class Relationships: • Cardinality (Fig. 12.3 page 396): • Identifies the number of objects involved in a relationship • Sometimes referred to as multiplicity • Lines (Fig. 12.7 page 398): • Connect related classes together • Most use solid lines • Dependency uses dotted lines • Also, sometimes inheritance with interfaces • Labels (Fig 12.3, page 397): • Used for Association • Verbs that help identify the activity taking place Wendi Jollymore, ACES

14. UML Notation • Notation for Class Relationships: • Symbols: • Connecting the lines and the symbols that represent classes/objects • Filled Triangles (Association – Fig. 12.3): • Used to show the direction of the activity • Diamonds (Aggregation/Composition – Fig. 12.5): • Filled - identifies composition • Empty – identifies aggregation • Arrows (Dependency – Fig 12.7): • The arrow pointing to the supplier class/object • Empty Triangles (Inheritance – Fig 12.9): • Used to show a parent/child relationship, where the arrow points to the parent. Wendi Jollymore, ACES

15. Exercise • A program reads inventory records from a file and then displays them in a GUI so a user can add/edit/delete records. • GUI Class – your interface • Product class – models one product in inventory • Inventory class – models a list of products • Will contain all the records in the file in the form of a list of Product objects Wendi Jollymore, ACES

16. Design Guidelines • Chapter 12.7 • Cohesion • Consistency • Encapsulation • Clarity • Completeness • Instance vs. Static • Inheritance vs. Aggregation • Interface vs. Abstract Classes Wendi Jollymore, ACES

17. Cohesion • A measure of the number of different responsibilities and operations in a class • A class should be dedicated to a single entity or purpose • Higher/stronger cohesion is desirable • Code is more reliable • Structure is easier to understand • Classes with low/weak cohesion: • Cluttered, too much going on in one class • Difficult to update/modify and debug • When used in another program, you might be bringing in too much functionality you don’t need Wendi Jollymore, ACES

18. Consistency • Obvious: • Java coding standards/style • Naming conventions for various elements/components • Where coding elements go • E.g. data members at the top • Consistency in names: • Use the same name for similar operations • E.g. read(), write(), size(), open() • Default constructors • Unless there’s a special reason, always provide a default constructor in every class Wendi Jollymore, ACES

19. Encapsulation • The “Black Box” • Someone using your class/method/whatever only needs to know what the element does, what goes in, and what should come out • They shouldn’t need to know what’s inside • They certainly shouldn’t need to modify your code!!! • Use private modifier to hide data • Use accessor/mutator methods where needed • Use private modifier for methods that don’t need to be accessed outside the class • E.g. “helper” methods don’t need to be public Wendi Jollymore, ACES

20. Clarity • Members should be intuitive • Examples • endingBalance is more descriptive than bal or b • getVolume() is more intuitive than vol() • Don’t define members that can be derived from other members • E.g. you don’t need a weeklyPay member if you already have weeklyHours and hourlyRate Wendi Jollymore, ACES

21. Completeness • Provide users (of your class(es)) with a variety of ways to construct and use your objects/classes • E.g. in the Inventory class: • Constructor that takes another array list • Constructor that takes a file directly • Constructor that takes a string for a file name • Default constructor that asks the user for the file to read • Provide constants for fixed data Wendi Jollymore, ACES

22. Instance vs. Static • Members specific to an instance of the class should be instance members • Members that are shared by the whole class should be class members • Examples: • lastName applies to a specific Employee instance • numberOfEmployees applies to all instances of the Employee class Wendi Jollymore, ACES

23. Inheritance vs. Aggregation • “is-a” vs. “has-a” • Inheritance: • A Bike is a Vehicle • A FullTimeEmployee is an Employee • Aggregation: • A Bike has a Gear System • An Employee has an Address • Inventory example: • Do you create a child class of ArrayList, or make your Inventory class have an ArrayList? Wendi Jollymore, ACES

24. Interfaces vs. Abstract Classes • Both are used to define common behavior in a set of objects (Inheritance) • Stronger inheritance relationships are classes • E.g. Shape/Circle/Cylinder • All Circles and Cylinders are Shapes • Weaker inheritance relationships are interfaces • Three-dimensional characteristics of shapes (e.g. the ability to calculate volume) • Only applies to some of the Shapes • This is more of a characteristic, than an object • Therefore, it would be an interface • “is kind of” –e.g. a Student who is a teaching assistant is “kind of” a teacher… Wendi Jollymore, ACES

25. Exercise • Do question 12.11 on page 417 • All of these are examples of poor design! • A. If you can obtain a value using other data field values, you don’t need that in your class – a program can do it on demand • B. Never force the user of your code to invoke methods in a certain order! • You can use private helper methods that work behind the scenes if you have to, but never do this with public methods Wendi Jollymore, ACES

26. Exercise • Continued… • C. This method it not using any of the instance members of the class, so it can be invoked without a class instance • Therefore, it should be static • D. Never use a constructor to initialize a static data field, otherwise the data field will be re-initialized each time an instance is created • Static data field values are supposed to be share across multiple instances Wendi Jollymore, ACES