Access Control

Package: The Library Unit

A package contains a groups of classes, organized together under a single namesapce.

The package statement must be the first non-comment code in the Java file.

Code Organization

In Java, a working program is a bunch of .class files, which can be packaged and compressed into a Java ARchive (JAR) file.

Creating Unique Package Names

Collecting the package files into a single subdirectory solves two other problems:

• Creating unique package names, and find those classes that might be buried in a directory structure someplace. (By convention, the first part of the package names is the reversed Internet domain name of the creator of the class).
• Resolving the package name into a directory on your machine, so that when Java program runs and it needs to load the .class file, it can locate the directory where the .class file resides.

Java interpreter proceeds as follows:

CLASSPATH=.;D:\JAVA\LIB;C:\DOC\JAVAT

• It finds the environment variable CLASSPATH (set via the operating system, can contain a number of alternative search paths). CLASSPATH contains one or more directories that are used as roots in a search for .class files.
• Starting at that root, the interpreter will take the package name and replace each do with a slash to generate a path name off the CLASSPATH root (so package foo.bar.baz becomes foo\bar\baz). 

If you have a '.' as one of the paths in your CLASSPATH, Java will look at the current directory as one of the starting points for searching.

Java Access Specifier

Access control is often referred to as implementation hiding. 

Wrapping data and methods within classes in combination with implementation hiding is often called encapsulation.

public: Interface Access

The member declaration that immediately follows public is available to everyone.

protected: Inheritance Access

The protected keyword deals with a concept called inheritance, which takes an existing class (base class) and adds new members to that class without touching the existing class.

default: Package Access

All the other classes in the current package have access to that member, but to all the classes outsides of this package, the member appears to be private.

This allows you to group related classes together in a package so that they can easily interact with each other.

Package access often provides an adequate amount of hiding, because package-access member is inaccessible to the client programmer using the class.

private: You Can't Touch That

No one can access that member except the class that contains that member, inside methods of that class.

In general case, you should make all fields private.

Class Access

A class cannot be private (that would make it inaccessible to anyone but the class) or protected. (actually, an inner class can be private or protected)

If you don't want anyone else to have access to that class, you can make all the constructors private, thereby preventing anyone but you, inside a static member of the class, from creating an object of that class.

class Soup1 {
  private Soup() {}
  // Allow creation via static method
  public static Soup1 makeSoup() {
    return new Soup1();
  }
}

Soup1, a static method is created that creates a new Soup1 and returns a reference to it.

If you want to do some extra operations on the Soup1 before returning it.

Or if you want to keep count of how many Soup1 objects to create (perhaps to restrict their population);

class Soup2 {
  private Soup2() {}
  // Create a satic object and return a reference
  // The "Singleton" pattern
  private static Soup2 ps1 = new Soup2();
  public static Soup2 access() {
    return ps1;
  }
}

Soup2 uses a singleton design pattern to allow only a single object to ever be created.

Summary

It is estimated that C programming project begins to break down somewhere between 50K and 100K lines of code because C has a single namespace, and names begin to collide, causing extra management overhead.

In Java, the package keyword, the package naming scheme, and the import keyword give you complete control over names, so the issue of name collision is easily avoided.

Two reasons for controlling access to members:

• Establish what the client programmers can and can't see.
• Allow the library designer to change the internal mechanisms of the class without worrying about how it will affect the client programmer. This separate the interface from the implementation.