Objects and classes - Data Structures and Problem Solving Using Java - page 95

3.8.4 package visibility rules

Packages have several important visibility rules. First, if no visibility
modifier is specified for a field, then the field is package visible . This
means that it is visible only to other classes in the same package. This is
more visible than private (which is invisible even to other classes in the
same package) but less visible than public (which is visible to nonpackage
classes, too).
Second, only public classes of a package may be used outside the pack-
age. That is why we have often used the public qualifier prior to class . Classes
may not be declared private . 3 Package-visible access extends to classes, too.
If a class is not declared public , then it may be accessed by other classes in the
same package only; this is a package-visible class . In Part IV, we will see that
package-visible classes can be used without violating information-hiding
principles. Thus there are some cases in which package-visible classes can be
very useful.
All classes that are not part of a package but are reachable through the
CLASSPATH variable are considered part of the same default package. As a
result, package-visible applies between all of them. This is why visibility is
not affected if the public modifier is omitted from nonpackage classes. How-
ever, this is poor use of package-visible member access. We use it only to
place several classes in one file, because that tends to make examining and
printing the examples easier. Since a public class must be in a file of the same
name, there can be only one public class per file.

Fields with no visi-
bility modifiers are
package visible ,
meaning that they
are visible only to
other classes in the
same package.

Non-public classes
are visible only to
other classes in the
same package.

a design pattern: composite (pair)

3.9

Although software design and programming are often difficult chal-
lenges, many experienced software engineers will argue that software
engineering really has only a relatively small set of basic problems. Per-
haps this is an understatement, but it is true that many basic problems are
seen over and over in software projects. Software engineers who are
familiar with these problems, and in particular, the efforts of other pro-
grammers in solving these problems, have the advantage of not needing
to “reinvent the wheel.”
The idea of a design pattern is to document a problem and its solution
so that others can take advantage of the collective experience of the entire

3. This applies to top-level classes shown so far; later we will see nested and inner classes,
which may be declared private .