Scope

where can variables appear?

after a class header but not in a method
   fields
inside the parens in a method header
   parameters to a method
   a special local variable
after a method header
   local varibles
static (class) variables

can they have the same name in different places?
  yes... and so you need to know, when you see a variable name,
  which declartion it matches.

cannot have two variables of the same name inside the same scope
  in different scopes, ok

scopes can overlap
  shadowing, hiding


--------------------------------------------------------------------------

defn:
  scope of a variable is the part of the program text where the variable 
  (storage space) can be "seen", or accessed by its name.

--------------------------------------------------------------------------

local variables
  declared inside methods (inc parameters)
  scope: begins at declaration, ends at end of the method
  access: statements after the decl, but only inside the method


============================================================================

public, private

though its bad practice, a method in one object can reach into another
object and get the value of a field directly.  We prefer to have the
other object give that field value through a method call, but Java
does allow this snitching behavior.

(demo)

to prevent it, you can declare a field "private"
then only methods in that class can access the field.

(demo)

--------------------------------------------------------------------------

What should be public, and what private?
As a rule of thumb: 

Classes are public. 
Fields are private. 
Constructors are public. 
Getter and setter methods are public. 
Other methods must be decided on a case by case basis. 
All of these rules may be freely violated if you have a reason for doing so. 
These are simply the defaults that handle 90% of the cases. 

--------------------------------------------------------------------------

Access protection has three main benefits: 

-- It allows you to enforce constraints on an object's state. 
-- It provides a simpler client interface. Client programmers don't 
   need to know everything that's in the class, only the public parts. 
-- It separates interface from implementation, allowing them to vary 
   independently. For instance consider making the licensePlate field 
   of Car an instance of a new LicensePlate class instead of a String. 


show the value of information hiding...
change implementations, using Rectangle

programs as contract