Java Reference
In-Depth Information
ing mixing these classes with our (more abstract) interface definitions. As language problems
go, this one is actually pretty benign. Exceptions tend to be fairly simple and often carry in-
formation that is going to be needed by any implementation's exception handlers. Where you
place them is more a matter of personal taste than design dictates (actually, most design dic-
tates boil down to personal taste, which doesn't make them any less correct, but that's the
subject of a different book). I prefer putting the exceptions thrown by methods defined in an
interface in the same package as the interfaces, and acknowledge that (in this one case) there
are implementation details that leak into the interface definitions. This means that I would be
importing two items from the interface namespace when I implement the
BatterImpl
class,
so the beginning of that class would look something like:
package com.oreilly.javaGoodParts.examples.impl;
import com.oreilly.javaGoodParts.examples.statistics.NotEnoughAtBatsException;
import com.oreilly.javaGoodParts.examples.statistics.Batter;
public class BatterImpl implements Batter {
...
You might choose to do things differently, and I would understand. But making use of the
package system to give yourself a way of grouping interacting components of your system is
a good thing about the language, so you shouldn't use the fact that exceptions keep it from
being pure and perfect as a reason not to use it as part of your design. Nor should you use it as
Packages and the Filesystem
While the inability to have some packages that are implementation-independent is regrettable,
the required interaction between the package system and the filesystem is both regrettable and
a pain. Simply put, the interaction is that whenever you declare a component in a package
name, you need to have a corresponding directory in your filesystem that corresponds to that
component. This is where the compiler will look for the source files that are defined in that
component, and this is where the classloaders will look for the object files that contain the bin-
aries for the classes in those packages. Most of us who use Java have become so used to this
that we don't even think about it. But it is strange and inconvenient, and has built up enough
supporting cruft that it is often confusing (and the source of interesting problems, which we
will see later). So I will end this chapter with some reflections on this oddity.
