RU beehive logo ITEC dept promo banner
ITEC 120
2009spring
ibarland
nokie
jmdymacek

home—info—lects—labs—exams—hws
textbook—tutor/PIs—java.lang docs—java.util docs

lect03c
designing an interface; signatures
method stubs

Last time, we wrote a test-class for a BankAccount. (What state and behaviors did that class have, again? Oh, right: it kept track of only one piece of state — a balance — and it had three behaviors (getBalance, deposit, withdraw).

Today, we'll actually write class BankAccount (and then check that it passes the BankAccountTester tests we wrote last time!)

Our test class was full of method calls — “asking questions of an object”. Today we'll look at the flip-side, writing methods — “telling objects how to answer questions”.

We'll start by talking about the signature for a method; this will be the other thing you'll need to memorize:

method-signature ::= return-type name( parameter-type&name )

We already figured out, that when somebody calls getBalance, they provide no additional information, and they expect to get a number back. Inside class BankAccount, we'll write: 

  double getBalance() {
    ...
    }
Note the parts of the signature.

Our test-cases also made it clear that when somebody calls deposit, they must provide the amount they want to deposit, and they don't expect any answer back: 

  void deposit( double amt ) {
    ...
    }
We call amt a parameter; it's like the “x” in algebra: it will stand for whatever number (argument) the caller provides. If this “parameter-type&name” parameters are local variables which are initialized when somebody calls the method.

Stub functions

The problem with just writing, say, 

public double getBalance() {
  ...
  }
is that the “...” doesn't actually compile. If you just want to check that your program (otherwise) compiles, you can replace the book's “...” with something which is syntatically correct (but is assuredly a logic-error). Since getBalance is contracted to return a double, we'll just return any ol' double: 
  public double getBalance() {
    return -12.345;
    }
This satisfies the signature, so the program will compile. (Of course, it's wrong that every BankAccount has a balance of negative $12.345. That's fine, we'll worry about the correct code later; for now it's important that we double-check we don't have any silly syntax errors before we go any further.) This is called a stub method, because we have placed a stub return in place of the real return we'll use eventually.

What about void methods, that don't return a value at all? You can leave those empty: 

  public void deposit() {
    }

  // This compiles as-is.

class BankAccount is a blueprint for creating individual BankAccount objects (or “instances”). Whenever some BankAccount gets asked (say) the getBalance question, that BankAccount will follow the instructions as given in that method.

Constructor signatures

We've mentioned that constructors are methods, but are a bit funny: instead of being called with 

method-call ::= object.methodName(args…)
calling a constructor starts with “new” and a space: 
constructor-call ::= new ClassName(args…)
(where the method-name must be the class-name).

Well, on the flip side of the coin, the syntax for a constructor's signature is a bit different too: instead of

method-signature ::= return-type name( parameter-type&name )
we have
constructor-signature ::= ClassName( parameter-type&name )
We see that constructor-signatures have two differences from regular signatures:

Let's add to our BankAccountTester class 

  BankAccount c = new BankAccount( 7.0 );
What will the signature look like, for this constructor? So we add this new constructor stub to our class BankAccount, and we go to compile our old BankAccountTester, and suddenly the previously-fine line b = new BankAccount(); doesn't work! It complains “Can't find BankAccount()” — that is, our new constructor takes a double, so it no longer likes constructing BankAccounts from zero arguments. We must go back and add a second constructor which takes no parameters, if we want to be able to create a new BankAccount either with or without an argument.

Now, if you've been watching closely, you'll wonder “wait — we never had a first version, with a constructor which took no inputs, so how did b = new BankAccount(); ever compile in the first place?” This is Java trying to fool us learners by being inconsistent: Usually we have to write every method, but:

gotcha: If you write a class and don't declare any constructor at all, Java writes one for you: a constructor with no inputs which does nothing.

class BankAccount (stubs)

home—info—lects—labs—exams—hws
textbook—tutor/PIs—java.lang docs—java.util docs

©2009, Ian Barland, Radford University
Last modified 2009.Feb.11 (Wed)		 Please mail any suggestions
(incl. typos, broken links)
to iba�rlandrad�ford.edu		 Powered by PLT Scheme