This chapter is from the book
This chapter is from the book
This chapter is from the book
5.2 Properties with Getters and Setters
When writing a Java class, we don’t like to use public fields:
public class Person { // This is Java
public int age; // Frowned upon in Java
}
With a public field, anyone could write to fred.age, making Fred younger or older. That’s why we prefer to use getter and setter methods:
public class Person { // This is Java
private int age;
public int getAge() { return age; }
public void setAge(int age) { this.age = age; }
}
A getter/setter pair such as this one is often called a property. We say that the class Person has an age property.
Why is this any better? By itself, it isn’t. Anyone can call fred.setAge(21), keeping him forever twenty-one.
But if that becomes a problem, we can guard against it:
public void setAge(int newValue) { if (newValue > age) age = newValue; }
// Can't get younger
Getters and setters are better than public fields because they let you start with simple get/set semantics and evolve them as needed.
NOTE
Just because getters and setters are better than public fields doesn’t mean they are always good. Often, it is plainly bad if every client can get or set bits and pieces of an object’s state. In this section, I show you how to implement properties in Scala. It is up to you to choose wisely when a gettable/settable property is an appropriate design.
Scala provides getter and setter methods for every field. Here, we define a public field:
class Person {
var age = 0
}
Scala generates a class for the JVM with a private age field and getter and setter methods. These methods are public because we did not declare age as private. (For a private field, the getter and setter methods are private.)
In Scala, the getter and setter methods are called age and age_=. For example,
println(fred.age) // Calls the method fred.age()
fred.age = 21 // Calls fred.age_=(21)
In Scala, the getters and setters are not named getXxx and setXxx, but they fulfill the same purpose. Section 5.5, “Bean Properties,” on page 61 shows how to generate Java-style getXxx and setXxx methods, so that your Scala classes can interoperate with Java tools.
NOTE
To see these methods with your own eyes, compile the Person class and then look at the bytecode with javap:
$ scalac Person.scala
$ javap -private Person
Compiled from "Person.scala"
public class Person extends java.lang.Object implements scala.ScalaObject{ private int age; public int age(); public void age_$eq(int); public Person(); }
As you can see, the compiler created methods age and age_$eq. (The = symbol is translated to $eq because the JVM does not allow an = in a method name.)
TIP
You can run the javap command inside the REPL as
:javap -private Person
At any time, you can redefine the getter and setter methods yourself. For example,
class Person {
private var privateAge = 0 // Make private and rename
def age = privateAge
def age_=(newValue: Int) {
if (newValue > privateAge) privateAge = newValue; // Can't get younger
}
}
The user of your class still accesses fred.age, but now Fred can’t get younger:
val fred = new Person
fred.age = 30
fred.age = 21
println(fred.age) // 30
NOTE
Bertrand Meyer, the inventor of the influential Eiffel language, formulated the Uniform Access Principle that states: “All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.” In Scala, the caller of fred.age doesn’t know whether age is implemented through a field or a method. (Of course, in the JVM, the service is always implemented through a method, either synthesized or programmer-supplied.)
TIP
It may sound scary that Scala generates getter and setter methods for every field. But you have some control over this process.
If the field is private, the getter and setter are private.
If the field is a val, only a getter is generated.
If you don’t want any getter or setter, declare the field as private[this] (see Section 5.4, “Object-Private Fields,” on page 60).