Re: Yet another OO question...

Chris, keep persevering and don't get too disheartened with your
progress - (you will eventually get the epiphany), or sidetracked with
the debates you have triggered on correct 'OO' or DB normalisation -
though there is some rich material there to sinks ones teeth into if you
have a mind - lol. Pity we can't be less belligerent in correcting each
other though. What has emerged over the last 10 years for the success of
a software project is for all members, including (if not especially)
software programmers to have good communication and interaction skills,
as well as to be team players, especially as projects increase in size
and cross time zones and cultures. Though from the tone of many
newsgroup "preachers", you wouldn't get that impression... Anyway, off
my own personal soapbox.

To do step one of my previous instructions, you needed to do something
similar to the following:

import java.io.*;
import java.util.Date;
import jxl.*;
import java.util.Calendar;

public class MyProg {

    public void myProgMethod() throws IOException,
jxl.read.biff.BiffException {

          /*Everything that I had in my static main void method
previously*/

    }

    public static void main(String[] args) {

        MyProg myProg = new MyProg();
        try {
            myProg.myProgMethod();
        } catch {Exception ex) {
            System.out.println(ex.getMessage());
        }

    }
}

A "static void main(String[] args) {}" method is an entry point into the
application. It has to reside in a class, though a class can only have
one main() method. However, an application can have a main() method in
every class if you want it to. When you call the application from the
command line: java class, the java application launcher will expect a
main() method in the class that you have nominated in the command line.
  This is sometimes useful for primitive testing, especially as a
beginner, to test the specific class. You probably have enough to get
your head around at the moment, so don't worry about using testing
frameworks just yet (yes I know, more experienced readers will be saying
heresy) like JUnit or TestNG. First get some comfort just being able to
instantiate an object using the "new" keyword.

Also, it is good practice (though others will have different opinions)
to explicitly state which classes you are importing rather than doing
the wild card package eg import java.util.Calendar; is better than
java.util.*;

Which brings up another topic. Take with a grain of salt anything that
is stated as being best practice in the software industry. Having
personally come from a medical background, and probably in your area
with the chemical sciences as well, best practice is something that has
been subject to blind trials, statistically based, is repeatable, and
subject to peer review. Due to the nature of software - cost,
creativity, variability of people, etc, you simply cannot subject a
process to the same rigour as is possible in engineering or other
sciences. Which 1. calls into question the appropriateness of the term
Computer Engineering and Computer Science when referring to software
development, and 2. often best practice in software development is
merely hyperbole for the latest fashion fad. Oops, getting back up on
my soap box again, so I will immediately yield and dismount.

Back to the task at hand. Remember that a class defines an object, and
in Java, almost nothing other than import statements occurs outside of a
class. An object is not instantiated or created until you call it with
the "new" operator. So to create an object, we need to do an Object
object = new Object(), which also calls that objects constructor on
creation. You have now created an object with a reference to it held in
the variable named object.

When using the "this" keyword, you are referring to methods or class
variables relating to the object that would be created from the class
that you are currently in. Very occasionally the "this" keyword is
required such as when a class variable has the same name as a method
parameter that you need to use, however in most cases it is not strictly
needed, but usually it is used as syntactic sugar to aid comprehension
and remove ambiguity. However, until you begin to conceptualise objects
in "3D" as opposed to viewing classes in "2D", this will be a difficult
concept to grasp. In fact, I believe that this ability, when looking at
a class, to conceptualise/visualise multiple individual concurrently
existing objects derived from that class is the first step towards
"getting" OO. While I understood the theory the first day it was
explained to me, it was like a revelation some time later when I
actually found myself thinking this way, rather than intellectualising
about cats and dogs being types of animals, or windows and doors being
objects within a house object.

So in the above example, the java application launcher when passed the
class name MyProg, looks for and finds the main() method, which it then
executes. We have not yet created an object. Instead, we are simply
running a special type of method (due to the static keyword) that is
contained in the class but this method has no concept of state, as it is
not part of any objects created from this class. In executing this main
() method, you create an object from the class within which you are
running with the MyProg myProg = new MyProg(); call. This leaves you
with a variable myProg that contains a reference to your newly created
object. Then you call a method on that newly created object with the
myProg.myProgMethod(); call, within which you execute what you were
attempting to do in the main() method previously. So are you confused yet?

This may be obvious, but I will say it anyway. The main() method only
exists if you specifically add a main() method to the class. Java will
not be able to start an application if you pass it the name of a class
in the command line that does not have a main() method that you have
explicitly added.

All the best with it,

AA