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
}