1 / 29

Class Relationships

CSCI 1260 – Lecture 2: Instantiation, Aggregation, and Composition. Class Relationships. Learning Objectives. Lecture Objectives : At the end of the lecture you should be able to: Draw/Produce UML diagrams ( instantiation relationship ) Implement and use the instantiation relationship

rachael
Download Presentation

Class Relationships

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CSCI 1260 – Lecture 2: Instantiation, Aggregation, and Composition Class Relationships Class Relationships

  2. Learning Objectives • Lecture Objectives: At the end of the lecture you should be able to: • Draw/ProduceUMLdiagrams (instantiation relationship) • Implementanduse the instantiation relationship • Produce UML diagrams (aggregate relationship) • Produce UML diagrams (composition relationship) • Implement and use the aggregationrelationship • Implement and use the compositionrelationship Class Relationships

  3. Instantiation Relationship The USES relationship Class Relationships

  4. Instantiation Relationship • In the instantiation relationship, one class usesthe services provided by another class. • Its objects instantiate and use objects of another class or classes. • An Employee object may use an object of the Name class to represent the person’s name and it may use an object of the Address class to manage the person’s address. • An Automobile object may use objects of the Engine, Transmission, Steering, SoundSystem, and other classes. • The user needs to know about the objects it is using, but the objects being used do not need to know abouttheiruser. • A Carpenter needs to know her Hammer but the Hammer doesn’t care who using it. • A Car needs to know about its Engine, but the Engine doesn’t care whether the Car is blue or white. • This promotes enhances separation of concerns, encapsulation, information hiding, and other object-oriented goals. Class Relationships

  5. Showing Instantiation in UML • In the diagram, objects of the class Person use the services of objects of the class Hammer • One shows an Instantiation relationship in UML with a dottedarrow pointing fromtheuser to the objectinuse Class Relationships

  6. Implementing the Instantiation Relationship • Typically, this relationship is implemented in Java code with a client method in the user class, say class A, instantiating an object of the other class, say class B, and then calling one or more methods of B on that object. Class Relationships

  7. Sample Code Skeleton A method in class Carpenter instantiates an object of class Hammer andthen uses it. Instantiation/Uses can also be implemented by passing an object of class Hammer to a method of class Carpenter and using it. Class Relationships

  8. The “Has-a” Relationship Composition and Aggregation: the whole-part relationships Class Relationships

  9. Aggregation and Composition • The relationship between two classes may be a part-whole relationship • The whole “has-a” part • Consider: • A room has a chair • A house has a roof • Both cases describe a part-whole relationship, where the room or the house is the whole and the chair or the roof is the part • In Java, the whole is a class (or instance thereof) and the part is an attribute of the class Class Relationships

  10. Aggregation and Composition • The two examples on the previous slide depict situations in which there is a very subtle difference in the relationships • The room has a chair but the chair is not an essential part of the room • The chair and the room may exist without the other • The chair may be removed from a room and placed in another – and both will continue to exist and function without the other • This relationship is called the aggregaterelationship (the chair and the room) • On the other hand: • The house has a roof • The roof is an essentialpart of the house; the house is incomplete without the roof • Neither the house nor the roof can exist without the other • This relationship is called the composition relationship (the roof is an essential component of the house) Class Relationships

  11. Composition and Aggregation • In both relationships, the class representing the whole has an attribute representing the part • In the composition relationship, the part and whole are created together • In Java, the part is instantiated in the constructor of the whole • The part and whole come into existence together and exist together until the whole ceases to exist (the house and its roof have the same lifetime) • In an aggregation relationship, the part is not created with the whole (i.e., in its constructor) • Some other method is provided to instantiate the part • This methodmay or maynot ever be invoked by the driver or some other class Class Relationships

  12. Aggregation Class Relationships

  13. Aggregation • In the aggregate relationship, one class aggregates objects of the other class • In the diagram, class Roomhas (or contains) zero or oneobjects of type Chair • The class Room, acting as the whole, maintains a reference (or references) to an object(s) of the class Chair that act as the part • There are usually one or more methods(that may or may not ever be invoked) that instantiate one or more instances of the part Reference name This type arrow indicates the aggregation relationship Between 0 and 1 instances of a Chair Class Relationships

  14. Aggregation in UML • In Jude/Astah*, the aggregation relationship is indicated as shown here: Use this dropdown … Select the Aggregation Symbol Tooltip helps one select the proper symbol … to get this list Class Relationships

  15. Aggregation in Jude • Drag the selected arrow FROM the “whole” (Room)TOthe “part” (Chair) The PART The WHOLE Arrow is the result of dragging FROM the Room class TO the Chair class Class Relationships

  16. Aggregation: code skeleton The Room has an attribute reference to a Chair object Room instantiates a reference to an object of type Chair – initially null Some method in Room associates the Room object with an actual Chair with the reference named chair Note that the Room object exists (and is initialized by the Room constructor – not shown) and the Chair object that is passed to the setChair method exists separately. The Chair becomes a real part of this Room only when this method is invoked Class Relationships

  17. Composition Class Relationships

  18. Composition • One class is partially or fully composed of objects of other classes • In the diagram, class House has (or contains) one object roof of type Roof • The class acting as the whole (House) maintains a reference (or references) to an object(s) of the class that is acting as the part (Roof) • The difference between this and aggregation is that the part is instantiated when the whole is instantiated. The house and the roof come into existence together (in the constructor for the House) Indicates a House object has exactly one Roof object, named roof This type of arrow indicates that the roof is an integral component of the house Class Relationships

  19. Composition in UML • Select the Composition Arrow in Jude/Astah*and DragFROM the whole (House) TO the part (Roof) Drag it FROM House TO Roof … Select this symbol … to get this Class Relationships

  20. Composition In aggregation, the part is created in a method that may or maynot ever be invoked, while here, the part is alwayscreated. Because the Roof/House cannot exist without the other, the Houseconstructor creates its own Roof – and the Roof object exists as long as the House object does Class Relationships

  21. Security Issues in Part-Whole Relationships Can something outside a class access a private member of the class without the class knowing it? Class Relationships

  22. Security Issues? • The textbook mentions a number of potential security issues with the aggregation/composition of classes • In the aggregation/composition relationship, you should restrictaccess to the aggregated/composedobjectreference by only allowing changes through the object that represents the whole • For example, we shouldnotallow the size of the roof to change unless the entirehouse is changed (by adding, removing, or changing parts of it) • The House may change its Roof, but we shouldn’t allow the Roof to change itself without the House’sknowledge or its control • The easiest way to do this, is to make sure the House owns the only copy of the Roof (so it can’t be changed elsewhere) • There is a security problem with the aggregation example code given earlier. What is it? Class Relationships

  23. Security Issues, cont. Object in memory 3 instances refer to it • Remember that an Object of a Class is a Reference to the actual object in memory • Multiple objectreferences may referto the sameactualobject in memory • Changing “one object” through its reference changes the actual object in memory so the othersarechanged, too Changing the attributes of a reference changes all 3 Class Relationships

  24. Example This technique is called a Shallow Copy because the reference is duplicated, but not the object to which it refers Class Relationships

  25. Example, continued This technique is called a Deep Copy because the object itself is duplicated – not just another reference to the same object Class Relationships

  26. Security Problems - resolved • The security problem noted several slides back can be resolved by ALWAYS using Deep Copy operations to assure that the only methods that can change a component object in a Compositeclass are the members of the Compositeclassitself • See the example on pages 358-359 (that starts several pages earlier) of the textbook for the right and wrong ways to handle this issue Class Relationships

  27. Correction to Aggregation Example • The correct code for the aggregation example to avoid the security issue is • One should almost always do this to prevent this type of security issue Room owns the clone of the parameter and only Room can change it. If the object that owns chairIn changes it, there will be no changes to the Room’schair. Class Relationships

  28. Copy Constructor • In a class, it may be desirable to initialize a new object as a duplicate of an existing object (as shown in a previous example) • This is done with a copy constructor • A copy constructor is a constructor that takes oneparameter – an existingobject of the sameclass • The copyconstructorinitializes the attributes of the newobject by copying the values of the correspondingattributes of the parameter into them • Example: Card myCard = new Card (yourCard); Initializes the new Card name myCard by copying all the attribute values from yourCard into the corresponding attributes in myCard Class Relationships

  29. Example of Copy Constructor Deep copy : copies the entire object – not just copy a reference to it into another reference Class Relationships

More Related