Lecture 6
20/01/11 01:32
Topic 6: Basics of Aggregation
• coverage of sec 8.1.1-8.1.4, with the exception of the latter part of sec 8.1.3
- recap of terminology from Fig 2.9 concerning feature, method, attribute, field.
one of the "take home" messages: the underlying issue with the topic of aggregation/composition is one of "power" (as in the power for a client to (potentially) modify an attribute of an object (suppose we call it A), where that attribute is itself an object (suppose we call it B). The fact that object A can have an attribute of type B is unremarkable. We already know that objects can have attributes of primitive and non-primitive types. The issue here is how do clients gain access to the attributes of object A (if at all).
One mechanism for clients to gain access to a class' attributes is if the class' implementer sets their visibility to public. This renders the attribute public, thus making it a field (e.g, Fraction.separator is the way in which a client can gain access to the field called "separator" of the class Fraction). But we covered in class the reasons why this design practice is frowned upon (see "In More Depth 2.6").
The other mechanism for clients to gain access to a class' attributes is if the class' implementer provides an accessor method (eg the "getSeparator()" method of Fraction). But what is the nature of the object that is returned by the accessor? Is it a reference to the actual object B or is it a reference to a object C, which is merely a copy of the object B. Clearly, if the implementer returns a copy, then this can allow the client to satisfy its curiousity about the state of object B, but the client will not be able to (purposely or inaderventently) modify the state of B.
• coverage of sec 8.1.1-8.1.4, with the exception of the latter part of sec 8.1.3
- recap of terminology from Fig 2.9 concerning feature, method, attribute, field.
one of the "take home" messages: the underlying issue with the topic of aggregation/composition is one of "power" (as in the power for a client to (potentially) modify an attribute of an object (suppose we call it A), where that attribute is itself an object (suppose we call it B). The fact that object A can have an attribute of type B is unremarkable. We already know that objects can have attributes of primitive and non-primitive types. The issue here is how do clients gain access to the attributes of object A (if at all).
One mechanism for clients to gain access to a class' attributes is if the class' implementer sets their visibility to public. This renders the attribute public, thus making it a field (e.g, Fraction.separator is the way in which a client can gain access to the field called "separator" of the class Fraction). But we covered in class the reasons why this design practice is frowned upon (see "In More Depth 2.6").
The other mechanism for clients to gain access to a class' attributes is if the class' implementer provides an accessor method (eg the "getSeparator()" method of Fraction). But what is the nature of the object that is returned by the accessor? Is it a reference to the actual object B or is it a reference to a object C, which is merely a copy of the object B. Clearly, if the implementer returns a copy, then this can allow the client to satisfy its curiousity about the state of object B, but the client will not be able to (purposely or inaderventently) modify the state of B.