prog 24178 object oriented programming ii with java prog 24178 object oriented programming ii with...

PROG 24178

Object Oriented Programming II

With Java

PROG 24178

Object Oriented Programming II

With Java

Class Relationships

04/20/23 Wendi Jollymore, ACES 2

Class RelationshipsClass Relationships

Chapter 12.4 in your textbook

Defines how classes relate to each other

How classes connect to each otherHow classes communicate with each otherHow classes work together


Class RelationshipsClass Relationships

AssociationAggregation / CompositionDependencyInheritance


AssociationAssociation

Defines the activity that takes place between two classesExample:

Student, Course, FacultyA student takes a courseA 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


Aggregation / CompositionAggregation / Composition

Defines ownership between classesOne class contains or owns parts

A “has a” relationship

Examples:A CD object can contain Song objectsA Student object owns a Name object

See Figure 12.5, page 397

Implemented using data membersSee bottom of page 397



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/classesExample:

An Address object can be owned by multiple Student objectsA Song object can be on many different CD objects



Composition:The aggregated object generally doesn’t exist without its aggregating object/classThe aggregated object is exclusive to the aggregating object/classExample:

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 objectA 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.


DependencyDependency

Defines classes that “use” each other or each other’s services

A “uses” relationship

The client class/object uses the supplier class/objectExample:

The ArrayList class uses the Object classSee Fig 12.7, page 398

Implemented in client class using methods

Contain a param of the supplier class type


CouplingCoupling

Coupling defines the amount of dependency between classes

Loose couplingLess dependency between classesChanges in one class don’t affect the other classes

Tight couplingMore dependency between classesChanges in one class greatly affect how the other classes function


CouplingCoupling

Association, Aggregation, Composition, and Dependency

Include some degree of dependencyInclude some degree of coupling

See 12.4.4, page 399Loose Coupling

Dependency

Tight Coupling

AssociationAggregation

Composition


InheritanceInheritance

Defines classes that have common characteristics (attributes, functionality)

An “is-a” relationshipStrong inheritance uses classesWeak inheritance uses interfaces

Examples:A Full-Time Employee is an Employee; a Salary Employee is an EmployeeA Car is a Vehicle; a bike is a VehicleA Cylinder is a Shape with 3d properties, a Square is a ShapeSee figure 12.9, page 399


ExerciseExercise

Do Question 12.2 on page 416See page 401 for the last one

Company/Employee: AggregationCourse/Faculty: AssociationStudent/Person: InheritanceHouse/Window: CompositionAccount/Savings Account: InheritanceJOptionpane/String: DependencyLoan/Date: Composition

UML NotationUML Notation

Notation for Class Relationships:Cardinality (Fig. 12.3 page 396):

Identifies the number of objects involved in a relationshipSometimes referred to as multiplicity

Lines (Fig. 12.7 page 398):Connect related classes togetherMost use solid linesDependency uses dotted lines

Also, sometimes inheritance with interfaces

Labels (Fig 12.3, page 397):Used for AssociationVerbs that help identify the activity taking place


UML NotationUML Notation

Notation for Class Relationships:Symbols:

Connecting the lines and the symbols that represent classes/objectsFilled Triangles (Association – Fig. 12.3):

Used to show the direction of the activityDiamonds (Aggregation/Composition – Fig. 12.5):

Filled - identifies compositionEmpty – 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.



ExerciseExercise

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 interfaceProduct class – models one product in inventoryInventory class – models a list of products

Will contain all the records in the file in the form of a list of Product objects

Design GuidelinesDesign Guidelines

Chapter 12.7CohesionConsistencyEncapsulationClarityCompletenessInstance vs. StaticInheritance vs. AggregationInterface vs. Abstract Classes


CohesionCohesion

A measure of the number of different responsibilities and operations in a classA class should be dedicated to a single entity or purposeHigher/stronger cohesion is desirable

Code is more reliableStructure is easier to understand

Classes with low/weak cohesion:Cluttered, too much going on in one classDifficult to update/modify and debugWhen used in another program, you might be bringing in too much functionality you don’t need


ConsistencyConsistency

Obvious:Java coding standards/styleNaming conventions for various elements/componentsWhere coding elements go

E.g. data members at the top

Consistency in names:Use the same name for similar operationsE.g. read(), write(), size(), open()

Default constructorsUnless there’s a special reason, always provide a default constructor in every class


EncapsulationEncapsulation

The “Black Box”Someone using your class/method/whatever only needs to know what the element does, what goes in, and what should come outThey shouldn’t need to know what’s insideThey certainly shouldn’t need to modify your code!!!

Use private modifier to hide dataUse 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


ClarityClarity

Members should be intuitiveExamples

endingBalance is more descriptive than bal or bgetVolume() 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


CompletenessCompleteness

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 listConstructor that takes a file directlyConstructor that takes a string for a file nameDefault constructor that asks the user for the file to read

Provide constants for fixed data04/20/23 Wendi Jollymore, ACES 21

Instance vs. StaticInstance vs. Static

Members specific to an instance of the class should be instance membersMembers that are shared by the whole class should be class membersExamples:

lastName applies to a specific Employee instancenumberOfEmployees applies to all instances of the Employee class


Inheritance vs. AggregationInheritance vs. Aggregation

“is-a” vs. “has-a”Inheritance:

A Bike is a VehicleA FullTimeEmployee is an Employee

Aggregation:A Bike has a Gear SystemAn Employee has an Address

Inventory example:Do you create a child class of ArrayList, or make your Inventory class have an ArrayList?


Interfaces vs. Abstract ClassesInterfaces 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/CylinderAll Circles and Cylinders are Shapes

Weaker inheritance relationships are interfacesThree-dimensional characteristics of shapes (e.g. the ability to calculate volume)Only applies to some of the ShapesThis is more of a characteristic, than an objectTherefore, it would be an interface“is kind of” –e.g. a Student who is a teaching assistant is “kind of” a teacher…


ExerciseExercise

Do question 12.11 on page 417All 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 demandB. 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


ExerciseExercise

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


prog 24178 object oriented programming ii with java prog 24178 object oriented programming ii with...

Documents