CS151 lecture notes, Fall 1999
Week 4, Monday

Reading:  4.8  through 4.13   BEFORE LAB ON WEDNESDAY

There will be an extrance quiz before you can begin
work on the lab.

A confusing thing
--------------------

When you are writing a method, you have to think from the
point of view of the programmer and the "user"

programmer -- person who writes a new method

user -- person who uses the new method

The "programmer" does not know what the values of the
parameters should be.  The "programmer" has to write the
body of the method so that it will work with any arguments.

The "user" chooses values for the arguments when he/she
invokes the method.  In general, the user only knows WHAT
the method does, not HOW it does it.  You should not assume
that the user knows anything about the body of the method.

It is sometimes confusing keeping track of which role you
are playing.


Why are we doing this?
---------------------

To control complexity:  we can only think about a few things
at a time (5-7 for most people; 23-37 for me, depending on my
blood sugar level).

Breaking large problem into subproblems makes it possible to
focus on one thing at a time...

      AS LONG AS THE SUBPROBLEMS ARE ISOLATED FROM EACH OTHER.

Methods are designed the way they are in order to maintain
that isolation.

That's why parameters and variables only exist within their
own methods.  That's right:


Local variables
---------------

When you declare a variable inside a method, it is a local
variable.  It exists only within its own method (after the
declaration.

The extent of the program where a varaible is defined is
called its "scope".

You can have different variables in different methods with
the same name.

With respect to "scope", parameters and variables are the
same.


Shadowing parameters
--------------------

Confusingly, it is also legal to have a parameter and a
variable with the same name, within the same method.

In that case, the variable shadows the parameter, making
it impossible to access the parameter.

Obviously, if we didn't need to access the value of the
parameter, it wouldn't be there, so shadowing is almost
never a good idea.

For our purposes, just don't do it.

I am just telling you about it so you recognize it if
you do it by accident.


Assigning values to parameters
------------------------------

A very common error for beginning programmers is to assign
values to the parameters:

  public static void printAmerican
       (String day, int date, String month, int year) {
    
    day = "Wednesday";           // WRONG!!!
    date = 17;                   // WRONG!!!
    month = "February";          // WRONG!!!
    year = 1999;                 // WRONG!!!

    System.out.println (day + ", " + month + " " + date + ", " + year);
  }

This is perfectly legal (unfortunately); it just doesn't
make any sense.

The parameters are supposed to be information that comes into
the method from outside.  In effect, you (as the person
writing the new method) are asking:  what date would you like
me to print?

It doesn't make sense to ask someone to provide a date, and then
promptly make up your own date and print it.


Remember

1) at the time when you write a method, you don't know the
values of the parameters, and it is not your job to set them

2) the "user" provides arguments when he/she invokes the
methods -- those will be the values of the parameters

3) you will almost never want to assign a value to a parameter
inside a method -- the values of the parameters are assigned
for you and it is seldom a good idea to change them


Examples:
---------

While you are writing multadd, you don't know what the
parameters will be, but you can write something that
will work for any values:

  public static void multadd (double a, double b, double c) {
    System.out.println (a * b + c);
  }

Then in main, you can test your program with simple values

  public static void main (String[] args) {
    multadd (1.0, 2.0, 3.0);
  }

Now you know multadd works and you never have to think about
it again.  You can use it to compute big complicated things,
without having to worry about how it works:

    double a = Math.cos (Math.PI / 4);
    double c = Math.sin (Math.PI / 4);
    multadd (a, 0.5, c);

    multadd (1.0, Math.log (10.0), Math.log (20.0));

In one case I used intermediate variables to make the
code easier to read.  I chose to use the same names as
the parameters, because it made sense to, but I didn't
have to, and I used the value 0.5 instead of something
named b.

Writing yikes is confusing because you are a "programmer"
with respect to yikes and a "user" with respect to multadd.

You don't know the value of x, but IF SOMEONE CAME ALONG AND
GAVE YOU ONE, you could compute the big hairy expression:

  public static void yikes (double x) {
    multadd (x, Math.exp(-x), Math.sqrt (1 - Math.exp(-x)));
  }

Notice that you (as yikes) don't have to print anything because
when you invoke multadd, it prints the result for you.


Pattern recognition
-------------------

In order to write yikes, you had to recognize that the expression
you were trying to evaluate was an example of a "solved problem."

In other words, multadd provides a general capability for solving
a class of problems (the ones that consist of a multiplication
and an addition).

Some problems, like 1.0 * 2.0 + 3.0  OBVIOUSLY fit this pattern.

But sometimes it takes a little thinking to see how the general
solution applies to a specific problem.

It's a good kind of thinking to practice!


EXAM #1 on WEDNESDAY