Java Reference
In-Depth Information
work, I prefix my packages with
com.sun
, which then only requires having a unique package
among those developed within one company (the prefix, needless to say, is a lot longer; the
company namespace is only the beginning). But I'm doing this work as part of a book, so I
will use the prefix
com.oreilly.javaGoodParts.examples
.
This will ensure that the names for classes and interfaces developed within the package struc-
ture are unique (unless someone else is writing a book with the same title for the same pub-
lisher). But we are going to go further than that and start breaking apart the structure of the
baseball statistics package, so that we can cluster parts that need to interact within the same
package and isolate those that don't need to interact in separate packages.
The first separation we can do is between the interfaces that define the external face of the
system and the implementations of those interfaces. We can place all of the interface defini-
tions (currently, those in the files
Batter.java
,
Catcher.java
, and
Fielder.java
) in the package:
com.oreilly.javaGoodParts.examples.statistics
by starting each of these files with the line:
package com.oreilly.javaGoodParts.examples.statistics;
The implementation classes will be placed in another package. For the moment, we will only
have a single implementation package:
com.oreilly.javaGoodParts.examples.impl
although that might change as the implementation gets more complex. The reason for this split
is to allow clients of the basic statistics storing classes to be dependent only on the interfaces
that define those classes, not on the implementation. By placing the interfaces in a separate
package, we can have multiple implementations (all in their own package or packages) and
the client will never be directly tied to any of them.
Splitting our code into separate packages is a form of refactoring that can ripple through our
code. Now that the interfaces are in a separate package, the classes that refer to those inter-
faces (which are all of them) need to import the interfaces, since they are no longer in the same
namespace. So along with a different package declaration, all of the implementation files will
need to be changed to include an import statement. For example, our
BatterImpl
class now
needs to be able to see the
Batter
interface, so we need to include the line:
