CS 303E Lecture 15: Method Wars' Methods I

1
CS 303E Lecture 15Method Wars. Methods I
E pluribus Unum. (One composed of many.) -
Virgil
2
Methods

• Methods are the most important part of a class to
  a class user.
• The public interface is the part of a class that
  is public.
• It shows what is visible to other classes and
  specifies what can be done with the class and
  objects of this type.
• Methods are a very important part of this
  interface

3
Preconditions and Postconditions

• The best comments for a method are pre and post
  conditions.
• preconditions are things the user of the method
  must ensure prior to calling the method
• postconditions are things the method (actually
  the writer of the method) guarantees to be true
  after the method is done IF the preconditions are
  met.

4
Example pre and post conditions

• Go back to the bank account example.
• A bank account has a balance and many methods
  including deposit.
• The header for deposit in the BankAccount class
  is
• public void deposit(double amount)
• What is the precondition?
• amount gt 0
• If the precondition can be expressed
  mathematically or in terms of other methods in
  the same class, so much the better.

5
Postcondition

• Postcondition for prime.
• balance old balance amount
• Now, what do we do if a user of this method
  doesn't meet the precondition?
• Print out an error message?
• we don't want most classes to deal with output.
  What if there is no console?
• Do nothing?
• during testing you may think the method is
  working correctly, but it isn't!

6
A somewhat costly mistake
Several earlier columns in IEEE Computer have
emphasized the importance of design by contract
for constructing reliable software. A
500-million software error provides a sobering
reminder that this principle is not just a
pleasant academic ideal. On June 4, 1996, the
maiden flight of the European Ariane 5 launcher
crashed about 40 seconds after takeoff. Media
reports indicated that the amount lost was half a
billion dollars -- uninsured. The CNES (French
National Center for Space Studies) and the
European Space Agency immediately appointed an
international inquiry board, made of respected
experts from major European countries, who
produced their report in hardly more than a
month. These agencies are to be commended for the
speed and openness with which they handled the
disaster. The committee's report is available on
the Web in these two places www.esrin.esa.it/ht
docs/tidc/Press/Press96/ariane5rep.html It is a
remarkably short, simple, clear and forceful
document. Its conclusion the explosion was the
result of a software error -- possibly the
costliest in history (at least in dollar terms,
since earlier cases have caused loss of life).
Particularly vexing is the realization that the
error came from a piece of the software that was
not needed during the crash. It has to do with
the Inertial Reference System, for which we will
keep the acronym SRI used in the report, if only
to avoid the unpleasant connotation that the
reverse acronym could evoke for US readers.
Before lift-off certain computations are
performed to align the SRI. Normally they should
be stopped at -9 seconds, but in the unlikely
event of a hold in the countdown resetting the
SRI could, at least in earlier versions of
Ariane, take several hours so the computation
continues for 50 seconds after the start of
flight mode -- well into the flight period. After
takeoff, of course, this computation is useless
but in the Ariane 5 flight it caused an
exception, which was not caught and -- boom. The
exception was due to a floating-point error a
conversion from a 64-bit integer to a 16-bit
signed integer, which should only have been
applied to a number less than 215, was
erroneously applied to a greater number,
representing the "horizontal bias" of the flight.
There was no explicit exception handler to catch
the exception, so it followed the usual fate of
uncaught exceptions and crashed the entire
software, hence the on-board computers, hence the
mission. This is the kind of trivial error that
we are all familiar with (raise your hand if you
have never done anything of the sort), although
fortunately the consequences are usually less
expensive. How in the world can it have remained
undetected, and produced such a horrendous
outcome?
7
Throwing Exceptions

• Exceptions are an indication that something very
  bad has happened.
• They can cause a program to crash or be caught
  and handled, hopefully recovering gracefully.
• public void deposit(double amount)
• if(amount lt 0)
• throw new IllegalArguementException()
• balance balance amount

8
Parameters

• A method header lists the parameters (a.k.a. the
  formal parameters for the method.)
• This is information sent into the method.
• Consider the bank account class again
• public void deposit(double amount)
• Amount is a parameter. The calling object is
  also a parameter, but it is an implicit
  parameter.
• A method call would be
• double dep 105.5
• oliviasAccount.deposit(dep)
• When the method is called you must specify
  arguments or actual parameters.

9
primitives vs. objects as parameters

• The way primitives and objects behave as
  arguments and parameters is vastly different.
• primitive parameters make and use a copy of the
  argument
• object parameters simply place another yellow
  sticky or label on objects that are arguments

BankAccount Object
105.5
105.5
this
50.90
myBalance
amount
dep
oliviasAccount
10
Implications of parameter behavior

• Although it is bad style a primitive parameter
  can be changed without affecting the argument
  that the parameter copied.
• Changes to object parameters are permanent! This
  can be very bad.
• Care must be taken when working with parameters
  that are objects

11
An equals method

• public boolean equals(BankAccount otherAccount)
• return myBalance otherAccount.balance
• if(mikesAccount.equals(oliviasAccount)

BankAccount Object
oliviasAccount
otherAccount
156.4
myBalance
BankAccount Object
mikesAccount
this
0.15
myBalance
12
Method types

• Accessor
• methods that return information about an object
  without changing it
• Mutator
• methods that modifies the state of an object in
  some way
• Normally good style to separate these two type of
  methods
• roll and getNumber from the Die class.