PROG Object Oriented Programming II With Java PROG Object Oriented Programming II With Java Class Relationships

11/11/2015Wendi Jollymore, ACES2 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

11/11/2015Wendi Jollymore, ACES3 Class Relationships Association Aggregation / Composition Dependency Inheritance

11/11/2015Wendi Jollymore, ACES4 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

11/11/2015Wendi Jollymore, ACES5 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

11/11/2015Wendi Jollymore, ACES6 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

11/11/2015Wendi Jollymore, ACES7 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.

11/11/2015Wendi Jollymore, ACES8 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

11/11/2015Wendi Jollymore, ACES9 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

11/11/2015Wendi Jollymore, ACES10 Coupling Association, Aggregation, Composition, and Dependency Include some degree of dependency Include some degree of coupling See , page 399 Loose Coupling Dependency Tight Coupling Association Aggregation Composition

11/11/2015Wendi Jollymore, ACES11 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

11/11/2015Wendi Jollymore, ACES12 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

UML Notation Notation for Class Relationships: Cardinality (Fig page 396): Identifies the number of objects involved in a relationship Sometimes referred to as multiplicity Lines (Fig 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 11/11/2015Wendi Jollymore, ACES13

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. 11/11/2015Wendi Jollymore, ACES14

11/11/2015Wendi Jollymore, ACES15 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

Design Guidelines Chapter 12.7 Cohesion Consistency Encapsulation Clarity Completeness Instance vs. Static Inheritance vs. Aggregation Interface vs. Abstract Classes 11/11/2015Wendi Jollymore, ACES16

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 11/11/2015Wendi Jollymore, ACES17

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 11/11/2015Wendi Jollymore, ACES18

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 11/11/2015Wendi Jollymore, ACES19

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 11/11/2015Wendi Jollymore, ACES20

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 11/11/2015Wendi Jollymore, ACES21

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 11/11/2015Wendi Jollymore, ACES22

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? 11/11/2015Wendi Jollymore, ACES23

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… 11/11/2015Wendi Jollymore, ACES24

Exercise Do question 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 11/11/2015Wendi Jollymore, ACES25

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 11/11/2015Wendi Jollymore, ACES26