new Foo(arg1, arg2, ..., argk)

public class Point
{
  private double x, y;
  
  public Point(double px, double py)
  {
    x = px;
    y = py;
  }
}

public class Ex01
{
  public static void main(String[] args)
  {
    double a = 0.5, b = 1.7;
    Point p;
    p = new Point(a,b);
  }
}

Static vs. non-static methods: how, why and which when? (Huh?)

Recall: a static method is just a regular old function — no this pointer is involved! Outside of the class, the call has to be prefaced with the class-name-"dot". A non-static method has a this-pointer, so it must be either called explicitly with an instance on the left (e.g. p.toString()) or called with an implicit this, which means that you're already in a member function where this.toString() and toString() are in fact synonymous.

So ... why would you choose to use a non-static in one case and a static in another?

• Definitely non-static: when you're getting information about a particular object, or modifying a particular object, you definitely want a non-static member function (an instance method in Java parlance). For example, if you were adding a method to compute a Point's distance from the origin, you'd definitely want to make that an instance method (non-static member-function):

  public double distance() { return Math.sqrt(x*x+y*y); }

  ... or a method to reflect a point with respect to the y axis:

  public void reflectMeXAxis() { y = -y; }

  Assuming we had a Point p already, these would be called like double d = p.distance(); and like p.reflectMeXAxis();. Note: What you'll find is that non-static (i.e. instance methods) is what you'll typically be doing. Why? Because only instance methods will allow for polymorphism, one of the fundamental mechanisms of OOP ... which we'll cover soon.
• Definitely static: When there is no Point to start off with, you'll make a static method. For example, a function to return a random point in the unit square [0,1]x[0,1]. (Note: the nextDouble() method of Random returns a random number in the range [0,1].)

  public static Point randomPointInUnitSquare(Random rand)
  {
    return new Point(rand.nextDouble(),rand.nextDouble());
  }

  Think about it this way: If you were to make this a member function, what would you do with the this pointer? Overwriting values in an existing point is undesireable, because then you have a two-step process of creating a point with dummy values for x and y, and then calling the function to modify those. The other option is to make a constructor that takes a Random object and does this, but that's undesireable if you also wanted to create points that were randomly distributed in the unit circle.

  Another great situation for a static method rather than a constructor or an instance method that modifies an object is when you sometimes will want to return a value that signals that the object you wanted couldn't be created. Reading from stdin to get a new point is an example. The read will fail if the user doesn't give you the right kind of data. If we have a static read function that returns a reference to the new Point that is read in, we can signal that something went wrong by returning null. You can't do this with a construtor or a method that is supposed to modify an object. Consider a "read" function for Points:

  public Point(Scanner sc) { ... } // Bad because you can't "return" null
  public void read(Scanner sc) { ... } // Bad because you can't "return" null
  public static Point read(Scanner sc) { ... } // Good because you can return null if something goes wrong

  Note: in a few weeks we'll talk about exceptions which will give us another way to handle this kind of thing.

• Could go either way: Sometimes it's a matter of taste whether to do something one way or another. Generally you should favor instance methods (i.e. non-static) as mentioned above. But sometimes it's a matter of asthetics. "Symmetric" operations involving two objects, meaning that neither is distinguished from the other, often seem awkward as instance methods. For example, if you want a function to test for equality between two points you could go with either

  public boolean equal(Point B) { return this.x == B.x && this.y == B.y; }

  or with

  public static boolean equal(Point A, Point B) { return A.x == B.x && A.y == B.y; }

  so that with Point's A and B you would either call with A.equal(B) or with Point.equal(A,B) You might prefer the static version because it treats both points the same: neither is "special", whereas with an instance method, one Point (A) "owns" the equality test. However, the Object-oriented philosophy says: make in an instance method unless there is a compelling reason not to. In other words, when in doubt make it an instance method. The reasons for this involve inheritance and polymorphism, which we haven't seen yet.

Instance variables vs. local variables

With all the newness, don't be confused about local variables. They work just as they always have: they are born at their point of declaration, die at the end of that function-call/block, and are only ever visible within that function/block. Thus, they are the ultimate in "hidden". Nothing outside of that block can ever touch them. So there is no public/private annotations for them. No need to do it, and it's not allowed! Public/private/protected — the access modifiers — apply to class definitions, fields (a.k.a. data members), and methods (a.k.a. member functions).

Object Oriented Design: Deciding what code goes where

A program built on the Object Oriented Programming paradigm organizes its code differently than a procedural program — meaning that where the code offering a particular piece of functionality goes is different. Part of getting used to OOP is making the right kind of decisions about what goes where. We're going to look at a few design decisions you have to make for Lab 3 and try to figure out what the most Object-Orientedy way is.

The Setup Recall that we have thre classes: Point, Box and Lab03. The general OOP design philosophy says that the code that has to do with points, without any particular reference to Lab03 or bounding boxes or any other specific problem that might involve points, should go in the Point class. The code that has to do with bouning boxes in general, without any particular reference to Lab03 or any other specific problem that might involve bounding boxes, should go in the Box class. Everything that's left should go in class Lab03.

Decision 1 - Where to read the word "add": The user inputs something like

add 3.5 -1.1

in order to "add" a new point to the bounding box. That means that somewhere in the program there has to be a

String comm = sc.next();
if (comm.equals("add"))
{
  ...

But where should that code go? In class Lab03? In class Box? In class Point? It needs to go into class Lab03! Why? Because it's only in the context of this program the word "add" pertains to points and bounding boxes. Another program that wants to compute with points or compute with bounding boxes might never read from a Scanner at all, much less read the word "add" and expect it to add a point to a bounding box! If you put this code in Box or in Point, you might be able to get your lab solution to work, but you would limit the liklihood that the classes Point and/or Box would be useful to future projects — and you'd make the code for this project harder to write, debug and understand.

Decision 2 - Where to put the code that prints out boxes in the xmin < x < xmax, ymin < y < ymax format: You'll have to have some code to do this, where should it go? You might argue that it should go into class Lab03 because that's the output format we want for this program, not necessarily others. You might argue it should go into class Box, because what could be more "about boxes" than printing out a description of a box? You might argue that it should be in class Point, because you need to access the private fields x and y of some Points in order to do the printing (this depends on what fields you chose to use for your box implementation). So, what do we do?

This code belongs in the class Box! It's about a box, and this may not be the only way to "print" a box, but it's a very natural and common way. You could provide multiple formats in different functions if future programs wanted something different, but still relying solely on the box itself. As for the argument for putting it in class Point, the solution is to extend the functionality of class point by adding "getter" functions:

public double getX() { ... }
public double getY() { ... }

to provide the needed values to the Box class. After all, the Box class is hardly the only class that might want to know a Point's x and y coordinates.

Code Reuse: Make the most out of your Objects!

One of the promised benefits of adhering to the discipline of Object Oriented Programing is code reuse, the idea that we can expect to be able to easily make use of code written in one project in another project. It also suggests that we should try to make use of existing classes when we can. So, once again, let's revisit Lab 3 and some of the choices we made in writing code for that Lab. When it came time to implement the class Box, there are at least three natural ways to represent the Box with your private data.

x/y bounds	height, width and lower left point	lower left and upper right points
We can represent a box by the values xmin, xmax, ymin and ymax. This is convenient for printing the way we have to.	We could remember the box by a reference point (lower left is pretty standard) and the box's width and height. This is not particularly convenient for the problems we need to solve.	We could represent a box by two points — the lower left and upper right points. If Point has the right methods, this can make things really convenient. What's nice, is that we benefit from our own code reuse, because we have all the Point methods at our disposal.

Initializing static fields (data members)

Non-static fields are initialized by constructors. What about static fields? There are two basic mechanisms for initializing them. The first is to give an initializing expression at the point at which the declaration takes place. E.g. the "= 0" in:

 private static int counter = 0;

But that doesn't work when there is code that needs to be executed, not just a simple expression. For this, we can add static initialization blocks or, more simply, we can add a static method and call it as the initializer expression, e.g.:

private static int[] squares = initSquares(10);

private static int[] initSquares(int n)
{
  int[] A = new int[n];
  for(int i = 1; i <= n; i++)
    A[i] = i*i;
}

The "final" modifier

In addition to public/private/protected and static, Java has a modifier "final". It means different things depending on whether it is used with a class, method or field definition. Its meanings for classes and methods involves inheritance, which we haven't yet studied, but its meaning with fields is pretty straightforward. A field, whether static or not, that is declared "final" never changes after it is given its initial value. So you might say something like:

private static final double PI = 3.14159;

... which means that PI is a double, it's a static field (a single variable PI shared by all instances of the class), it's private (can't be accessed outside of the class), and it's final, which means that it's value can never change from the 3.14159 it was originally assigned.

Java style

Java's API is a huge part of any Java program you write, and it follows a very strict set of conventions. Therefore, since we don't want two different sets of conventions running around, we always follow the same conventions in our code. The basics are:

1. Class names begin with an upper-case letter and otherwise follow "Camel Case" — separate words are squished together, but each new word starts with a captial letter. E.g. TimeOfDay.
2. Method and non-final field names begin with a lower-case letter and otherwise follow Camel Case. E.g. growBy.
3. Constants (e.g. fields declared "final") are all upper-case.
4. Comments should precede every method and every class definition, at a minimum. Java has a unique way of including comments for methods/classes that you should follow. It is not with the // characters:

   /**
    * This class does X, Y, and Z
    * You should use it!
    */
   public static class Commenter {
       /**
        * This method makes no sense, but the comments are great.
        */
       public String toString() {
          return "hellooooo";
       }
   
       /**
        * This method adds two numbers.
        */
       public int add(int num1, int num2) {
          return num1+num2;
       }
   
   }
   

Java's printf

Sometimes System.out.println( ) is painful to use. The PrintStream (which is what System.out is) also has "printf", which behaves similarly to C's printf. So for example:

public class Ex1
{
  public static void main(String[] args)
  {
    double x = 0.2373451, y = 1.8021234;
    System.out.printf("%1.3f divided by %1.3f is %1.5f\n",x,y,x/y);
  }
}

produces the following output when run

~/$ java Ex1
0.237 divided by 1.802 is 0.13170

See the documentation for more details.

Primitive wrapper classes

Java distinguishes between primitive types and objects primarily for performance reasons. It complicates things, though. Moreover, you sometimes want a double or an int to behave like an object — for example when you'd like to dinstinguish between the absence of a value (null) as opposed to a zero value (0 or 0.0). Java has class version of the primitive types, called Primitive wrapper classes. They are class Integer, Double, Character, Byte and Boolean. Objects of these types are immutable (like strings, they cannot be changed). Here's an example that uses the Integer class so that null can signal the absence of a value.

import java.util.*;

public class Ex2
{
  public static void main(String[] args)
  {
    Scanner sc = new Scanner(System.in);
    Integer I = null;
    while(I == null)
    {
      System.out.print("Enter an integer: ");
      if (!sc.hasNextInt())
	sc.nextLine();
      else
	I = sc.nextInt();
    }
    System.out.println("You entered " + I);
  }
}

Here's a sample run:

~/$ java Ex2
Enter an integer: I = 23
Enter an integer: twenty
Enter an integer: help?
Enter an integer: 23
You entered 23