Adding behavior to a Java object
Person is looking good so far, but it could use some additional behavior to make it more interesting. As you've already learned, creating behavior means adding methods. This section looks more closely at accessor methods — namely, the getters and setters you've already seen in action. You'll also learn syntax for calling methods.
In order to encapsulate a class's data from other objects, you declare its variables to
be private and then provide accessor methods. As you know, a getter is an accessor method for retrieving the value of an attribute; a setter is an accessor method for modifying that value. The naming of accessors follows a strict convention known as the JavaBeans pattern, whereby any attribute Foo has a getter called getFoo() and a setter called setFoo().
The JavaBeans pattern is so common that support for it is built right into the Eclipse IDE. You've even already seen it in action — when you generated getters and setters for Person in the preceding section.
Accessors follow these guidelines:
- The attribute itself is always declared with
privateaccess. - The access specifier for getters and setters is
public. - Getters don't take any parameters and return a value whose type is the same as the attribute it accesses.
- Settings only take one parameter, of the type of the attribute, and do not return a value.
By far the easiest way to declare accessors is to let Eclipse do it for you, as shown back in Figure 6. But you should also know how to hand-code a getter-and-setter pair. Suppose you have an attribute, Foo, whose type is java.lang.String. A complete declaration for it (following the accessor guidelines) would be:
private String foo;
public String getFoo() {
return foo;
}
public void setFoo(String value) {
foo = value;
}
|
You may notice right away that the parameter value passed to the setter is named differently than if it had been generated by Eclipse. This is my own convention, and one I recommend to other developers. On the rare occasion that I do hand-code a setter, I always use the name value as the parameter value to the setter. This eye-catcher reminds that I've hand-coded the setter. Because I usually allow Eclipse to generate getters and setters for me, when I don't there's a good reason for it. Using value as the setter's parameter value reminds me that this setter is special. (Code comments could also do that.)
Invoking, or calling, methods is easy. You saw in Listing 7 how to invoke the various getters of Person to return their values. Now I'll formalize the mechanics of making method calls.
Method invocation with and without parameters
To invoke a method on an object, you need a reference to that object. Method-invocation syntax comprises the object reference, a literal dot, the method name, and any parameters that need to be passed:
objectReference.someMethod(); objectReference.someOtherMethod(parameter); |
Here is a method invocation without parameters:
Person p = /*obtain somehow */; p.getName(); |
And here is a method invocation with parameters (accessing the Name attribute of Person):
Person p = new Person("Joe Q Author", 42, 173, 82, "Brown", "MALE");
|
Remember that constructors are methods, too. And you can separate the parameters with spaces and newlines. The Java compiler doesn't care. These next two method invocations are identical:
new Person("Joe Q Author", 42, 173, 82, "Brown", "MALE");
|
new Person("Joe Q Author",
42,
173,
82,
"Brown",
"MALE");
|
Method invocations can also be nested:
Logger l = Logger.getLogger(Person.class.getName());
l.info("Name: " + p.getName());
|
Here you are passing the return value of Person.class.getName() to the getLogger() method. Remember that the getLogger() method call is a static method call, so its syntax differs slightly. (You don't need a Logger reference to make the invocation; instead, you just use the name of the class itself as the left-hand side of the invocation.)
That's really all there is to method invocation.




