java2.txt

这是一些介绍JAVA的东东,主要面对要学习JAVA的朋友,28天来对JAVA有一个比较系统的了解.

  * Creating Your Own Packages
    * Pick a Package Name
    * Create the Directory Structure
    * Use package to Add Your Class to a Package
    * Packages and Class Protection

  * What Are Interfaces?
    * The Problem of Single Inheritance
    * Abstract Design and Concrete Implementation
    * Interfaces and Classes

  * Implementing and Using Interfaces
    * The implements Keyword
    * Implementing Multiple Interfaces
    * Other Uses of Interfaces

  * Creating and Extending Interfaces
    * New Interfaces
    * Methods Inside Interfaces
    * Extending Interfaces
    * An Example: Enumerating Linked Lists

  * Summary
  * Q&A


Packages and interfaces are two capabilities that allow you
greater control and flexibility in designing sets of
interrelated classes. Packages allow you to combine groups of
classes and control which of those classes are available to the
outside world; interfaces provide a way of grouping abstract
method definitions and sharing them among classes that may not
necessarily acquire those methods through inheritance.

Today you'll learn how to design with, use, and create your own
packages and interfaces. Specific topics you'll learn about
today include
  * A discussion of designing classes versus coding classes and
    how to approach each
  * What packages are and why they are useful for class design
  * Using other people's packages in your own classes
  * Creating your own packages
  * What interfaces buy you in terms of code reuse and design
  * Designing and working with interfaces

Programming in the Large and Programming in the Small

When you examine a new language feature, you should ask yourself
two questions:
  * How can I use it to better organize the methods and classes
    of my Java program?
  * How can I use it while writing the actual Java code?

The first is often called programming in the large, and the
second, programming in the small. Bill Joy, a founder of Sun
Microsystems, likes to say that Java feels like C when
programming in the small and like Smalltalk when programming in
the large. What he means by that is that Java is familiar and
powerful like any C-like language while you're coding individual
lines, but has the extensibility and expressive power of a pure
object-oriented language like Smalltalk while you're designing.

The separation of "designing" from "coding" was one of the most
fundamental advances in programming in the past few decades, and
object-oriented languages such as Java implement a strong form
of this separation. The first part of this separation has
already been described on previous days: When you develop a Java
program, first you design the classes and decide on the
relationships between these classes, and then you implement the
Java code needed for each of the methods in your design. If you
are careful enough with both these processes, you can change
your mind about aspects of the design without affecting anything
but small, local pieces of your Java code, and you can change
the implementation of any method without affecting the rest of
the design.

As you begin to explore more advanced Java programming, however,
you'll find that this simple model becomes too limiting. Today
you'll explore these limitations, for programming in the large
and in the small, to motivate the need for packages and
interfaces. Let's start with packages.

What Are Packages?

Packages, as mentioned a number of times in this book so far,
are a way of organizing groups of classes. A package contains
any number of classes that are related in purpose, in scope, or
by inheritance.

Why bother with packages? If your programs are small and use a
limited number of classes, you may find that you don't need to
explore packages at all. But the more Java programming you do,
the more classes you'll find you have. And although those
classes may be individually well designed, reusable,
encapsulated, and with specific interfaces to other classes, you
may find the need for a bigger organizational entity that allows
you to group your packages.

Packages are useful for several broad reasons:
  * They allow you to organize your classes into units. Just as
    you have folders or directories on your hard disk to
    organize your files and applications, packages allow you to
    organize your classes into groups so that you only use what
    you need for each program.
  * They reduce problems with conflicts in names. As the number
    of Java classes grows, so does the likelihood that you'll
    use the same class name as someone else, opening up the
    possibility of naming clashes and errors if you try to
    integrate groups of classes into a single program. Packages
    allow you to "hide" classes so that conflicts can be
    avoided.
  * They allow you to protect classes, variables, and methods in
    larger ways than on a class-by-class basis, as you learned
    yesterday. You'll learn more about protections with packages
    later today.
  * They can be used to identify your classes. For example, if
    you implemented a set of classes to perform some purpose,
    you could name a package of those classes with a unique
    identifier that identifies you or your organization.

Although a package is most typically a collection of classes,
packages can also contain other packages, forming yet another
level of organization somewhat analogous to the inheritance
hierarchy. Each "level" usually represents a smaller, more
specific grouping of classes. The Java class library itself is
organized along these lines. The top level is called java; the
next level includes names such as io, net, util, and awt. The
last of these has an even lower level, which includes the
package image.

                                                                 
  Note                                                           
                                                                 
  By convention, the first level of the hierarchy specifies      
  the (globally unique) name to identify the author or owner     
  of those packages. For example, Sun Microsystems's classes,    
  which are not part of the standard Java environment, all       
  begin with the prefix sun. Classes that Netscape includes      
  with its implementation are contained in the netscape          
  package. The standard package, java, is an exception to this   
  rule because it is so fundamental and because it might         
  someday be implemented by multiple companies.                  
                                                                 
  I'll tell you more about package-naming conventions later      
  when you create your own packages.                             
                                                                 
Using Packages

You've been using packages all along in this book. Every time
you use the import command, and every time you refer to a class
by its full package name (java.awt.Color, for example), you've
used packages. Let's go over the specifics of how to use classes
from other packages in your own programs to make sure you've got
it and to go into greater depth than we have in previous
lessons.

To use a class contained in a package, you can use one of three
mechanisms:
  * If the class you want to use is in the package java.lang
    (for example, System or Date), you can simply use the class
    name to refer to that class. The java.lang classes are
    automatically available to you in all your programs.
  * If the class you want to use is in some other package, you
    can refer to that class by its full name, including any
    package names (for example, java.awt.Font).
  * For classes that you use frequently from other packages, you
    can import individual classes or a whole package of classes.
    After a class or a package has been imported, you can refer
    to that class by its class name.

What about your own classes in your own programs that don't
belong to any package? The rule is that if you don't
specifically define your classes to belong to a package, they're
put into an unnamed default package. You can refer to those
classes simply by class name from anywhere in your code.

Full Package and Class Names

To refer to a class in some other package, you can use its full
name: the class name preceded by any package names. You do not
have to import the class or the package to use it this way:

java.awt.Font f = new java.awt.Font()

For classes that you use only once or twice in your program,
using the full name makes the most sense. If, however, you use
that class multiple times, or if the package name is really long
with lots of subpackages, you'll want to import that class
instead to save yourself some typing.

The import Command

To import classes from a package, use the import command, as
you've used throughout the examples in this book. You can either
import an individual class, like this:

import java.util.Vector;

or you can import an entire package of classes, using an
asterisk (*) to replace the individual class names:

import java.awt.*

                                                                 
  Note                                                           
                                                                 
  Actually, to be technically correct, this command doesn't      
  import all the classes in a package-it only imports the        
  classes that have been declared public, and even then only     
  imports those classes that the code itself refers to. You'll   
  learn more on this in the section titled "Packages and Class   
  Protection."                                                   
                                                                 
Note that the asterisk (*) in this example is not like the one
you might use at a command prompt to specify the contents of a
directory or to indicate multiple files. For example, if you ask
to list the contents of the directory classes/java/awt/*, that
list includes all the .class files and subdirectories, such as
image and peer. Writing import java.awt.* imports all the public
classes in that package, but does not import subpackages such as
image and peer. To import all the classes in a complex package
hierarchy, you must explicitly import each level of the
hierarchy by hand. Also, you cannot indicate partial class names
(for example, L* to import all the classes that begin with L).
It's all the classes in a package or a single class.

The import statements in your class definition go at the top of
the file, before any class definitions (but after the package
definition, as you'll see in the next section).

So should you take the time to import classes individually or
just import them as a group? It depends on how specific you want
to be. Importing a group of classes does not slow down your
program or make it any larger; only the classes you actually use
in your code are loaded as they are needed. But importing a
package does make it a little more confusing for readers of your
code to figure out where your classes are coming from. Using
individual imports or importing packages is mostly a question of
your own coding style.

                                                                 
  Technical Note                                                 
                                                                 
  Java's import command is not at all similar to the #include    
  command in C-like languages, although they accomplish          
  similar functions. The C preprocessor takes the contents of    
  all the included files (and, in turn, the files they           
  include, and so on) and stuffs them in at the spot where the   
  #include was. The result is an enormous hunk of code that      
  has far more lines than the original program did. Java's       
  import behaves more like a linker; it tells the Java           
  compiler and interpreter where (in which files) to find        
  classes, variables, method names, and method definitions. It   
  doesn't bring anything into the current Java program.          
                                                                 
Name Conflicts

After you have imported a class or a package of classes, you can
usually refer to a class name simply by its name, without the
package identifier. I say "usually" because there's one case
where you may have to be more explicit: when there are multiple
classes with the same name from different packages.

Here's an example. Let's say you import the classes from two
packages from two different programmers (Joe and Eleanor):

import joesclasses.*;
import eleanorsclasses.*;

Inside Joe's package is a class called Name. Unfortunately,
inside Eleanor's package there is also a class called Name that
has an entirely different meaning and implementation. You would
wonder whose version of Name would end up getting used if you
referred to the Name class in your own program like this:

Name myName = new Name("Susan");

The answer is neither; the Java compiler will complain about a
naming conflict and refuse to com