© 2006-2007 Carl Alphonce & Adrienne Decker 1 ; Chapter 4 Composition and Association ; Pedagogic Motivations We introduce two new relationships that can exist between classes: composition and association. These relationships will allow us to build more elaborate domain models. We discuss the scope and lifetime of local and instance variables. Methods are introduced as a way of defining capabilities for objects. Modeling with relationships This chapter introduces two new relationships that can exist between objects. Unlike the dependency relationships we discussed in the previous chapter, which are fleeting in nature, the relationships discussed in this chapter persist for a longer period of time. Another important concept introduced in this chapter is that of non-constructor methods. Each capability we identify for our objects is defined by a method in the class definition. Methods are also used to help set up relationships, such as association. The lifetime of these relationships is captured using different types of variables. The short-lived dependency relationships we saw last chapter are created either without a variable (an instantiation dependency) or with a local variable (a local variable dependency). The longer-lived relationships of this chapter make use of a variable called an instance variable. This chapter includes a discussion of some important differences between local variables and instance variables. Capabilities and Methods An object communicates with another object by sending a message to it. The effect of the message is to trigger a capability on the receiving object (i.e. the receiving object performs the indicated capability). In Java, an object‟s response for a given capability is defined by a method. Another way of saying this is that a method defines the response of an object to a given message. When one object sends a message to another object, we typically say that the first object invokes (or calls) a method on the second object. Example 1 Suppose we are modeling how a painter paints rooms in houses, with the aim of building an automatic house-painting robot. Included in this model may well be things like rooms, paint cans, paint brushes, colors and a model of the painter (which will be realized as a robot). The painter has paint cans containing paint of different colors, and different paint brushes, which it uses to apply color to the walls of a room.Chapter 4: Composition and Association 2 © 2006-2007 Carl Alphonce & Adrienne Decker We can send a message to the painter to change the color of the paint that is being used, perhaps by saying “Please change your paint color to sweet blue”. Notice that not only do we need to tell the painter what we want done (change the paint color) but we also need to say to what color we want to change (sweet blue). We can send another message to the painter, asking which color is currently being used to paint with, perhaps by saying “Pray tell, what paint color are you using now?” When we ask a question like this we expect to receive a response, maybe something like “sea foam green”. Example 2 One of the things we would like to do with a bank account is to check our balance. Suppose the bank account‟s response to the “what is my balance” query is defined by a method named checkBalance. The way we send a “what is my balance” query is by invoking (or calling) the checkBalance method on the bank account object. Each capability we identify for an object during our modeling of a problem domain corresponds to a method; each method forms a part of the class definition for the object. Method definition Just like a class or a constructor definition, a method definition consists of two parts: a header and body. A method header has various parts, some required and some optional (to begin with we will ignore some of the optional parts; we will introduce them as needed). A method body consists of a sequence of statements which describe how to respond to the invocation of the method. The method body therefore provides procedural information1 about what actions should be performed when the method is called. This will be realized by a sequence of statements about what activities the method should perform. Information about what the method should do is written as a comment. Comments are written for human readers of a program. The compiler ignores comments, and they have no effect on the meaning of a program. In Java there are two forms of comments one can write. The first is a single-line comment, which can start at any point in a line (the start of the comment is indicated by double forward slashes, as in “//”), and continues to the end of a line. The second is a block comment. A block comment starts with “/*” and ends with “*/”. A block comment includes all the text between “/*” and “*/”. The method header The header of a method specifies certain information which is needed in order to invoke the method, such as the name of the method, whether the method requires information from the caller to do its job, and whether or not the method returns any value to its caller. 1 Procedural information is “how to” information. Procedural information gives the steps an object must follow in order to carry out a method invocation.Capabilities and Methods © 2006-2007 Carl Alphonce & Adrienne Decker 3 Java requires that these bits of information be given in a particular order. Recall from the previous chapter our convention of writing in italics those pieces of Java syntax which are placeholders for information you provide. We will describe the structure of a method header as follows: public type identifier (formal parameter-list) There are three placeholder parts to this header definition: something called type, something called identifier, and something called formal parameter-list. Let us deal with the most familiar one first: the identifier in the method header is the name that we will give to the method. The rules for naming methods are the same as those for naming classes. The conventions are a little different. Recall that rules must be followed, whereas conventions are guidelines which are a good idea to follow, but which you are not bound to follow.2 The conventions of method naming are:  Method names begin with a lower case letter.  The underscore character „_‟, while a legal part of an identifier, is typically not used