260 likes | 399 Views
Class Relationships. 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. Class Relationships. Association Aggregation / Composition Dependency
E N D
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
Class Relationships • Association • Aggregation / Composition • Dependency • Inheritance Wendi Jollymore, ACES
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
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
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
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
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
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
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
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
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
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
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
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
Design Guidelines • Chapter 12.7 • Cohesion • Consistency • Encapsulation • Clarity • Completeness • Instance vs. Static • Inheritance vs. Aggregation • Interface vs. Abstract Classes Wendi Jollymore, ACES
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
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
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
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
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
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
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
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
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
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