OOP with Encapsulation/Data Hiding

Reprising constructors

Suppose we have a class named Foo. The only way to instantiate an object of class Foo is with a "new-expression". To understand what happens when a new-expression is evaluated, consider an expression of the form:

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

1. A new Foo object is created, with all fields set to 0/0.0/false/null.
2. The k-argument constructor whose parameters match the types of arg1,...,argk is called with it's this pointer/reference pointing to the newly created Foo object. Note that the constructor does not return anything ... it's goal is just to perform initialization for the newly created object. You the programmer never "call" a constructor. It is called by the new operator.
3. Once the constructor has completed, the evaluation of the new expression is complete. The value of the new expression is a reference to the newly created-and-initialized Foo object.

Note: If you do not have a constructor for a class, one will be created for you (the Miranda rights of OOP?). It will be a default constructor, which means a constructor with no arguments, and it simply initializes everything to 0/0.0/false/null. If, on the other hand, you create even just one constructor, then only the constructor(s) you create will be available — the compiler will not create one for you.

Example of a Constructor in Action

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.

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 three classes: Point, Box and Lab03. The general OOP design philosophy says that the code that has to do with points should go in the Point class (without any particular reference to Lab03 or bounding boxes or any other specific problem that might involve points). The code that has to do with bouning boxes in general should go in the Box class (without any particular reference to Lab03 or any other specific problem that might involve bounding boxes). 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

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

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() { ... }

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.