Java基础重温(十)-scjp 2

11.But while an abstract class can define both abstract and non-abstract

methods, an interface can have only abstract methods. Another way interfaces

differ from abstract classes is that interfaces have very little flexibility in how the

methods and variables defined in the interface are declared. These rules are strict:

■ All interface methods are implicitly public and abstract. In other words,

you do not need to actually type the public or abstract modifiers in the

method declaration, but the method is still always public and abstract.

■ All variables defined in an interface must be public, static, and final—

in other words, interfaces can declare only constants, not instance variables

■ Interface methods must not be static.

■ Because interface methods are abstract, they cannot be marked final,

strictfp, or native. (More on these modifiers later.)

■ An interface can extend one or more other interfaces.

■ An interface cannot extend anything but another interface.

■ An interface cannot implement another interface or class.

■ An interface must be declared with the keyword interface.

■ Interface types can be used polymorphically (see Chapter 2 for more details).

Look for interface methods declared with any combination of public, abstract,

or no modifiers. For example, the following five method declarations, if declared

within their own interfaces, are legal and identical!

void bounce();

public void bounce();

abstract void bounce();

public abstract void bounce();

abstract public void bounce();

12.What about a subclass that tries to inherit a private member of its superclass?

When a member is declared private, a subclass can't inherit it. For the exam, you

need to recognize that a subclass can't see, use, or even think about the private

members of its superclass. You can, however, declare a matching method in the

subclass. But regardless of how it looks, it is not an overriding method! It is simply a

method that happens to have the same name as a private method (which you're not

supposed to know about) in the superclass. The rules of overriding do not apply, so

you can make this newly-declared-but-just-happens-to-match method declare new

exceptions, or change the return type, or anything else you want to do with it.

13.Can a private method be overridden by a subclass? That's an interesting

question, but the answer is technically no. Since the subclass, as we've seen, cannot

inherit a private method, it therefore cannot override the method—overriding

depends on inheritance.

14.Whereas default access doesn't extend any special consideration to subclasses

(you're either in the package or you're not), the protected modifier respects the

parent-child relationship, even when the child class moves away (and joins a

new package). So, when you think of default access, think package restriction. No

exceptions. But when you think protected, think package + kids. A class with a

protected member is marking that member as having package-level access for all

classes, but with a special exception for subclasses outside the package.

But what does it mean for a subclass-outside-the-package to have access to a

superclass (parent) member? It means the subclass inherits the member. It does not,

however, mean the subclass-outside-the-package can access the member using a

reference to an instance of the superclass. In other words, protected = inheritance.

Protected does not mean that the subclass can treat the protected superclass member

as though it were public. So if the subclass-outside-the-package gets a reference to

the superclass (by, for example, creating an instance of the superclass somewhere

in the subclass' code), the subclass cannot use the dot operator on the superclass

reference to access the protected member. To a subclass-outside-the-package, a

protected member might as well be default (or even private), when the subclass is

using a reference to the superclass. The subclass can see the protected member

only through inheritance.

15.No! Once the subclass-outside-the-package inherits the protected member,

that member (as inherited by the subclass) becomes private to any code outside

the subclass, with the exception of subclasses of the subclass. So if class Neighbor

instantiates a Child object, then even if class Neighbor is in the same package as

class Child, class Neighbor won't have access to the Child's inherited (but protected)

variable x. Figure 1-4 illustrates the effect of protected access on classes and subclasses

in the same or different packages.

16. You can, however, have an abstract class with no abstract methods. The following

example will compile fine:

public abstract class LegalClass{

void goodMethod() {

// lots of real implementation code here

}

}

17. Any class that extends an abstract class must implement all abstract methods

of the superclass, unless the subclass is also abstract. The rule is this:

The first concrete subclass of an abstract class must implement all abstract

methods of the superclass.

18.Any class that extends an abstract class must implement all abstract methods

of the superclass, unless the subclass is also abstract. The rule is this:

The first concrete subclass of an abstract class must implement all abstract

methods of the superclass.

Concrete just means nonabstract, so if you have an abstract class extending

another abstract class, the abstract subclass doesn't need to provide implementations

for the inherited abstract methods. Sooner or later, though, somebody's going to

make a nonabstract subclass (in other words, a class that can be instantiated),

and that subclass will have to implement all the abstract methods from up the

inheritance tree.

19. Finally, you need to know that the abstract modifier can never be combined

with the static modifier. We'll cover static methods later in this objective, but

for now just remember that the following would be illegal:

abstract static void doStuff();

And it would give you an error that should be familiar by now:

MyClass.java:2: illegal combination of modifiers: abstract and

static

abstract static void doStuff();

20. but for now all

we're concerned with is knowing that the synchronized modifier can be applied

only to methods—not variables, not classes, just methods. A typical synchronized

declaration looks like this:

public synchronized Record retrieveUserInfo(int id) { }

You should also know that the synchronized modifier can be matched with any

of the four access control levels (which means it can be paired with any of the three

access modifier keywords).

21. The native modifier indicates that a method is implemented in platform-dependent

code, often in C. You don't need to know how to use native methods for the

exam, other than knowing that native is a modifier (thus a reserved keyword) and

that native can be applied only to methods—not classes, not variables, just methods.

Note that a native method's body must be a semicolon (;) (like abstract methods),

indicating that the implementation is omitted.

22. You'll want to study the IEEE 754 if you need something to help you fall asleep.

For the exam, however, you don't need to know anything about strictfp other

than what it's used for, that it can modify a class or method declaration, and that a

variable can never be declared strictfp.

23. As a bit of background, we'd like to clarify how we're going to use the terms

"argument" and "parameter" throughout this book.

■ arguments The things you specify between the parentheses when you're

invoking a method:

doStuff("a", 2); // invoking doStuff, so a & 2 are arguments

■ parameters The things in the method's signature that indicate what the

method must receive when it's invoked:

void doStuff(String s, int a) { } // we're expecting two

// parameters: String and int

24. We'll cover using var-arg methods more in the next few chapters, for now let's

review the declaration rules for var-args:

■ Var-arg type When you declare a var-arg parameter, you must specify the

type of the argument(s) this parameter of your method can receive. (This can

be a primitive type or an object type.)

■ Basic syntax To declare a method using a var-arg parameter, you follow the

type with an ellipsis (...), a space, and then the name of the array that will

hold the parameters received.

■ Other parameters It's legal to have other parameters in a method that uses

a var-arg.

■ Var-args limits The var-arg must be the last parameter in the method's

signature, and you can have only one var-arg in a method.

Let's look at some legal and illegal var-arg declarations:

Legal:

void doStuff(int... x) { } // expects from 0 to many ints

// as parameters

void doStuff2(char c, int... x) { } // expects first a char,

// then 0 to many ints

void doStuff3(Animal... animal) { } // 0 to many Animals

Illegal:

void doStuff4(int x...) { } // bad syntax

void doStuff5(int... x, char... y) { } // too many var-args

void doStuff6(String... s, byte b) { } // var-arg must be last

25. The first thing to notice is that constructors look an awful lot like methods. A

key difference is that a constructor can't ever, ever, ever, have a return type…ever!

Constructor declarations can however have all of the normal access modifiers, and

they can take arguments (including var-args), just like methods. The other BIG

RULE, to understand about constructors is that they must have the same name as

the class in which they are declared. Constructors can't be marked static (they

are after all associated with object instantiation), they can't be marked final

or abstract (because they can't be overridden). Here are some legal and illegal

constructor declarations:

class Foo2 {

// legal constructors

Foo2() { }

private Foo2(byte b) { }

Foo2(int x) { }

Foo2(int x, int... y) { }

// illegal constructors

void Foo2() { } // it's a method, not a constructor

Foo() { } // not a zmethod or a constructor

Foo2(short s); // looks like an abstract method

static Foo2(float f) { } // can't be static

final Foo2(long x) { } // can't be final

abstract Foo2(char c) { } // can't be abstract

Foo2(int... x, int t) { } // bad var-arg syntax

}