PROG 24178 Object Oriented Programming II With Java

PROG 24178 Object Oriented Programming II With Java 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 3/12/2021 Wendi Jollymore, ACES 2

Class Relationships Association Aggregation / Composition Dependency Inheritance 3/12/2021 Wendi Jollymore, ACES 3

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 3/12/2021 Wendi Jollymore, ACES 4

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 3/12/2021 Wendi Jollymore, ACES 5

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 3/12/2021 Wendi Jollymore, ACES 6

Aggregation / 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. 3/12/2021 Wendi Jollymore, ACES 7

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 Array. List 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 3/12/2021 Wendi Jollymore, ACES 8

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 3/12/2021 Wendi Jollymore, ACES 9

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 3/12/2021 Wendi Jollymore, ACES 10

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 3 d properties, a Square is a Shape See figure 12. 9, page 399 3/12/2021 Wendi Jollymore, ACES 11

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 3/12/2021 Wendi Jollymore, ACES 12

UML 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 3/12/2021 Wendi Jollymore, ACES 13

UML 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. 3/12/2021 Wendi Jollymore, ACES 14

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 3/12/2021 Wendi Jollymore, ACES 15

Design Guidelines Chapter 12. 7 Cohesion Consistency Encapsulation Clarity Completeness Instance vs. Static Inheritance vs. Aggregation Interface vs. Abstract Classes 3/12/2021 Wendi Jollymore, ACES 16

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 3/12/2021 Wendi Jollymore, ACES 17

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 3/12/2021 Wendi Jollymore, ACES 18

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 3/12/2021 Wendi Jollymore, ACES 19

Clarity Members should be intuitive Examples ending. Balance is more descriptive than bal or b get. Volume() is more intuitive than vol() Don’t define members that can be derived from other members E. g. you don’t need a weekly. Pay member if you already have weekly. Hours and hourly. Rate 3/12/2021 Wendi Jollymore, ACES 20

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 3/12/2021 Wendi Jollymore, ACES 21

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: last. Name applies to a specific Employee instance number. Of. Employees applies to all instances of the Employee class 3/12/2021 Wendi Jollymore, ACES 22

Inheritance vs. Aggregation “is-a” vs. “has-a” Inheritance: A Bike is a Vehicle A Full. Time. Employee is an Employee Aggregation: A Bike has a Gear System An Employee has an Address Inventory example: Do you create a child class of Array. List, or make your Inventory class have an Array. List? 3/12/2021 Wendi Jollymore, ACES 23

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… 3/12/2021 Wendi Jollymore, ACES 24

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 3/12/2021 Wendi Jollymore, ACES 25

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 3/12/2021 Wendi Jollymore, ACES 26