CS 46A - Lecture 23

Pre-class reading

• Sections 8.6 - 8.7, 8.9

Static Variables

• A static variable belongs to the class, not to any object of the class:

  public class BankAccount
  {
     private double balance;
     private int accountNumber;
     private static int lastAssignedNumber = 1000;
     ...
  }

  If lastAssignedNumber was not static, each instance of BankAccount would have its own value of lastAssignedNumber

• public BankAccount()
  {
     lastAssignedNumber++; // Updates the static variable
     accountNumber = lastAssignedNumber; // Sets the instance variable
  }

A Static Variable and Instance Variables

Static Variables

• Three ways to initialize:
  1. Do nothing. Variable is initialized with 0 (for numbers), false (for boolean values), or null (for objects)
  2. Use an explicit initializer, such as

     public class BankAccount
     {
        private static int lastAssignedNumber = 1000;
        . . .
     }

  3. Use a static initialization block
• Static variables should always be declared as private
• Exception: Static constants, which may be either private or public:

  public class BankAccount
  {
     . . .
     public static final double OVERDRAFT_FEE = 5; // Refer to it as BankAccount.OVERDRAFT_FEE
  }

• Minimize the use of static variables (static final variables are ok)

Lecture 23 Clicker Question 1

Harry tells you that he has found a great way to avoid those pesky objects and classes: Put all code into a single class and declare all methods and variables static. Then main can call the other static methods, and all of them can access the static variables. What do you think of Harry's plan?

1. It won't work—you can't avoid using objects and classes
2. It won't work—you can't call other static methods from main
3. It will work, and it will make programs simpler to understand
4. It will work, but it will make programs harder to understand

Scope of Local Variables

• Scope of variable: Region of program in which the variable can be accessed
• Scope of a local variable extends from its declaration to end of the block that encloses it
• Sometimes the same variable name is used in two methods:

  public class RectangleTester
  {
     public static double area(Rectangle rect)
     {
        double r = rect.getWidth() * rect.getHeight();
        return r;
     }
     public static void main(String[] args)
     {
        Rectangle r = new Rectangle(5, 10, 20, 30);
        double a = area(r);
        System.out.println(r);
     }
  }

• These variables are independent from each other; their scopes are disjoint

Scope of Local Variables

• Scope of a local variable cannot contain the definition of another variable with the same name:

  Rectangle r = new Rectangle(5, 10, 20, 30);
  if (x >= 0)
  {
     double r = Math.sqrt(x);
     // Error - can't declare another variable called r here
     . . .
  }

• However, can have local variables with identical names if scopes do not overlap:

  if (x >= 0)
  {
     double r = Math.sqrt(x);
     . . .
     } // Scope of r ends here
  else
  {
     Rectangle r = new Rectangle(5, 10, 20, 30);
     // OK - it is legal to declare another r here
     . . .
  }

Overlapping Scope

• A local variable can shadow a variable with the same name:
• Local scope wins over class scope:

  public class Coin
  {
     private String name;
     private double value; // Instance variable 
     . . .
     public double getExchangeValue(double exchangeRate)
     {
        double value; // Local variable with the same name
        . . .
        return value;
     }
  }

• Access shadowed variables by qualifying them with the this reference:

  value = this.value * exchangeRate;

Overlapping Scope

• Generally, shadowing an instance variable is poor code — error-prone, hard to read
• Exception: when implementing constructors or setter methods, it can be awkward to come up with different names for instance variables and parameters
• OK:

  public Coin(double value, String name) 
  { 
     this.value = value; 
     this.name = name; 
  }

Lecture 23 Clicker Question 2

Consider the following program that uses two variables named r. 

public class RectangleTester 
{ 
   public static double area(Rectangle rect) 
   {  
      double r = rect.getWidth() * rect.getHeight(); 
      return r; 
   } 
   public static void main(String[] args) 
   { 
      Rectangle r = new Rectangle(5, 10, 20, 30); 
      double a = area(r); 
      System.out.println(r); 
   } 
}

• This class has an error. You cannot have two variables with the same name in the same class.
• This class has an error. The scopes of the two variables r overlap.
• The error in this class can be fixed by using this.r instead of r
• This class doesn't have any errors.

Packages

• Package: Set of related classes
• Important packages in the Java library:

  Package	Purpose	Sample Class
  java.lang	Language support	Math
  java.util	Utilities	Random
  java.io	Input and output	PrintStream
  java.awt	Abstract Windowing Toolkit	Color
  java.applet	Applets	Applet
  java.net	Networking	Socket
  java.sql	Database Access	ResultSet
  javax.swing	Swing user interface	JButton
  omg.w3c.dom	Document Object Model for XML documents	Document

Organizing Related Classes into Packages

• To put classes in a package, you must place a line

  package packageName;

  as the first instruction in the source file containing the classes

• Package name consists of one or more identifiers separated by periods
• For example, to put the Financial class introduced into a package named com.horstmann.bigjava, the Financial.java file must start as follows:

  package com.horstmann.bigjava;
  
  public class Financial
  {
     . . .
  }

• Default package has no name, no package statement

Syntax 8.2 Package Specification

Importing Packages

• Can always use class without importing:

  java.util.Scanner in = new java.util.Scanner(System.in);

• Tedious to use fully qualified name
• Import lets you use shorter class name:

  import java.util.Scanner;
   . . .
  Scanner in = new Scanner(System.in)

• Can import all classes in a package:

  import java.util.*;

• Never need to import java.lang
• You don't need to import other classes in the same package

Package Names

• Use packages to avoid name clashes

  java.util.Timer

  vs.

  javax.swing.Timer

• Package names should be unambiguous
• Recommendation: start with reversed domain name:

  com.horstmann.bigjava

• edu.sjsu.cs.walters for Britney Walters' classes (walters@cs.sjsu.edu)

Packages and Source Files

• Base directory: holds your program's Files
• Path name, relative to base directory, must match package name:

  com/horstmann/bigjava/Financial.java

  

Lecture 23 Clicker Question 3

Which of the following are packages?

• java
• java.lang
• java.util
• java.lang.Math

1. The first three
2. The last three
3. The middle two
4. All of them

Lecture 23 Clicker Question 4

Harry has found a great way of getting rid of all those pesky import statements. Instead of placing import java.util.Random at the top of the program, he simply writes java.util.Random instead of Random inside the program. What do you think?

1. It won't work—you must use import statements to import packages other than java.lang
2. It won't work—it's a syntax error to put the package name before a class.
3. It works, and it makes programs simpler to read
4. It works, but it makes programs harder to read