PROG 24178 Object Oriented Programming II With Java PROG 24178 Object Oriented Programming II With Java Class Relationships.
Post on 04-Jan-2016
237 Views
Preview:
Transcript
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
04/20/23 Wendi Jollymore, ACES 3
Class RelationshipsClass Relationships
AssociationAggregation / CompositionDependencyInheritance
04/20/23 Wendi Jollymore, ACES 4
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
04/20/23 Wendi Jollymore, ACES 5
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
04/20/23 Wendi Jollymore, ACES 6
Aggregation / CompositionAggregation / 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/classesExample:
An Address object can be owned by multiple Student objectsA Song object can be on many different CD objects
04/20/23 Wendi Jollymore, ACES 7
Aggregation / CompositionAggregation / Composition
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.
04/20/23 Wendi Jollymore, ACES 8
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
04/20/23 Wendi Jollymore, ACES 9
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
04/20/23 Wendi Jollymore, ACES 10
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
04/20/23 Wendi Jollymore, ACES 11
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
04/20/23 Wendi Jollymore, ACES 12
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
04/20/23 Wendi Jollymore, ACES 13
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.
04/20/23 Wendi Jollymore, ACES 14
04/20/23 Wendi Jollymore, ACES 15
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
04/20/23 Wendi Jollymore, ACES 16
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
04/20/23 Wendi Jollymore, ACES 17
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
04/20/23 Wendi Jollymore, ACES 18
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
04/20/23 Wendi Jollymore, ACES 19
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
04/20/23 Wendi Jollymore, ACES 20
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
04/20/23 Wendi Jollymore, ACES 22
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?
04/20/23 Wendi Jollymore, ACES 23
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…
04/20/23 Wendi Jollymore, ACES 24
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
04/20/23 Wendi Jollymore, ACES 25
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
04/20/23 Wendi Jollymore, ACES 26
top related