java
// Demonstrates "private" keyword
class Sundae {
private Sundae() {}
static Sundae makeASundae() {
return new Sundae();
}
}
public class IceCream {
public static void main(String[] args) {
//! Sundae x = new Sundae();
Sundae x = Sundae.makeASundae();
}
} ///:~
This shows an example in which private comes in handy: you might want to control how an object is created and prevent someone from directly accessing a particular constructor (or all of them). In the example above, you cannot create a Sundae object via its constructor; instead you must call the makeASundae( ) method to do it for you.3
3 There’s another effect in this case: Since the default constructor is the only one defined, and it’s private, it will prevent inheritance of this class. (A subject that will be introduced in Chapter 6.) Chapter 5: Hiding the Implementation
177
Any method that you’re certain is only a “helper” method for that class can be made private to ensure that you don’t accidentally use it elsewhere in the package and thus prohibit you from changing or removing the method. Making a method private guarantees that you retain this option. (However, just because the handle is private doesn't mean that some other object can't have a public handle to the same object. See Chapter 12 for issues about aliasing.)
protected: “sort of friendly”
The protected access specifier requires a jump ahead to understand. First, you should be aware that you don’t need to understand this section to continue through the book up through the inheritance chapter. But for completeness, here is a brief description and example using protected.
The protected keyword deals with a concept called inheritance, which takes an existing class and adds new members to that class without touching the existing class, which we refer to as the base class. You can also change the behavior of existing members of the class. To inherit from an existing class, you say that your new class extends an existing class, like this:
class Foo extends Bar {
The rest of the class definition looks the same.
If you create a new package and you inherit from a class in another package, the only members you have access to are the public members of the original package. (Of course, if you perform the inheritance in the same package, you have the normal package access to all the “friendly” members.) Sometimes the creator of the base class would like to take a particular member and grant access to derived classes but not the world in general. That’s what protected does. If you refer back to the file Cookie.java on page 175, the following class cannot access the “friendly” member:
//: ChocolateChip.java
// Can't access friendly member
// in another class
import c05.dessert.*;
public class ChocolateChip extends Cookie {
public ChocolateChip() {
System.out.println(
"ChocolateChip constructor");
}
public static void main(String[] args) {
ChocolateChip x = new ChocolateChip();
//! x.foo(); // Can't access foo
}
} ///:~
One of the interesting things about inheritance is that if a method foo( ) exists in class Cookie, then it also exists in any class inherited from Cookie. But since foo( ) is “friendly” in a foreign package, it’s unavailable to us in this one. Of course, you could make it public, but then everyone would have access and maybe that’s not what you want. If we change the class Cookie as follows:
public class Cookie {
178
Thinking in Java
www.BruceEckel.com
public Cookie() {
System.out.println("Cookie constructor");
}
protected void foo() {
System.out.println("foo");
}
}
then foo( ) still has “friendly” access within package dessert, but it is also accessible to anyone inheriting from Cookie. However, it is not public.
Interface and implementation
Access control is often referred to as implementation hiding. Wrapping data and methods within classes (combined with implementation hiding this is often called encapsulation) produces a data type with characteristics and behaviors, but access control puts boundaries within that data type for two important reasons. The first is to establish what the client programmers can and can’t use. You can build your internal mechanisms into the structure without worrying that the client programmers will think it’s part of the interface that they should be using.
This feeds directly into the second reason, which is to separate the interface from the implementation. If the structure is used in a set of programs, but users can’t do anything but send messages to the public interface, then you can change anything that’s not public (e.g. “friendly,” protected, or private) without requiring modifications to their code.