To Kathy&Bert and others: Java p. 97 question

[Clovis Hartig II]

Hi everybody,

I hope this is the correct forum to post a question about the book "Head First Java". I'm working my way through this fine, fine book and have a very simple question:

The brain barbell on p. 97 asks us how we would decide which class or classes to build first when writing a program. Although I know we should come up with the answer ourselves, I would like to know how an experienced programmer would answer this.

Thanks. And I did try searching through some of the individual forums to see if this was asked before and looked on the book's companion website, I wasn't able to find anything related to this, but I am sorry if this was asked and answered before.
[ September 12, 2004: Message edited by: Clovis Hartig II ]

[Ray Muirhead]

Working on a project right now and having this exact problem - I'd also be very interested in what some of you more experienced programmers have to say .

It is hard to get started .

[JulianInactive KennedyInactive]

Hi guys,

OK, my advice would be to sort out the basic application architecture first. Put a skeleton in place for how the main backbone of the application is going to work. Keep it simple. That's worth repeating. Keep it simple! You want to try and work it so that you always have something that basically works as far as it has been completed. Don't code for days without running and testing your app.

Next, or even first if you prefer, tackle any areas of the application that you're unsure about. Do the bits you don't know how to do first. You can easily code most of your app based on false assumptions about how an area you were unsure about is going to work or is going to fit in.

Start with an outline design and look at refining that design as you go along. Seek to factor out common code into separate methods and groups of related methods with a common purpose into separate classes. It can be trial and error at first, but that's part of the fun.

Leave all the whistles and bells and fine-tuning to last. Your app can probably do without most of it and if the deadline's drawing near you can still deliver on time and add the niceties later.

Alternatively, failing all that, just pick the parts you fancy and code them first! Delegate the boring stuff to your team. That's what I do.

Jules

[Ray Muirhead]

Thanks Jules - that was really helpful. I think you may have just saved my project from several weeks - months wasted time (seriously ) I'd started on the easy stuff, and your response made me think about my whole approach.

Cheers,

Ray

[Clovis Hartig II]

Yes, thanks Jules, very helpful. Does anyone else have an addition? Not that Jules' answer was not comprehensive and on target. I'm just wondering how Kathy Sierra and Bert Bates might have imagined the answer to the question in the book. Specifically, how would they decide which classes should be created first? Would it be the driving class with main and then each of the other classes? If so, how would we decide which of those come first after the tester class with main? If not, same question I guess

[Stan James]

There's a neat practice going around call Programming by Intention. It means making your code say what it is you're doing as clearly as possible. This is useful in smaller programs, say school assignments, and in individual classes in larger programs.

Say you got an assignment to read a file containing numbers, compute the sum and average, and print the results. A neat starting point would be:

public static void main(String[] args)
{
   new TestClass().doAssignment(args[0]);
}
public void doAssignment(fileName)
{
   readFile(fileName);
   computeSums();
   computeAverage();
   reportResults();
}

See how easy it is to understand the problem we're solving? And how easy it is to guess what each of those other methods do?

If you can find a starting point for your program, the first class can look just this simple. Admittedly it's tougher in a giant system with a Swing or web front-end where it's not obvious where things start.

oops. gotta run. More later if you like.

[Clovis Hartig II]

Thanks Stan! You da man That gives me even more direction and its something I'll start doing now. This is a great way to break it down.

Although you've done plenty, if you want to write more as you mentioned, yes give us more pearls of wisdom

[Stan James]

What I didn't get to say last night was ... some larger programs use very complex event driven techniques, so it's very hard to see where they start. A Swing program might retrieve some data and build a screen and then just wait for user input. It can be tough to read one and figure out how anything gets done.

As for writing such things, try to focus on the bits that do real work first. Say you were asked to put a Swing interface on the little example I gave before, let the user enter some number of integers then sum & average. I sure wouldn't start with the Swing interface. I'd start with something that gets an array of numbers and does sums. Then add average. Then maybe think about the screens.

I may blow us right out of the beginner forum, but if you are ambitious, look into JUnit testing at JUnit.org. There is a great paper there called
Test Infected: Programmers Love Writing Tests that may get you hooked on writing TESTS first. Very cool.

[Clovis Hartig II]

Thanks again Stan. More very useful stuff. I will be working with Swing and AWT so I will definitely keep what you have said in mind. I'm also looking forward to looking into JUNit...

[Dan Walin]

I wonder if there is no "right answer" to this. Personally, I would code the smaller, utility-type classes first. That way I could test each on it's own before having them used by other, higher-level classes. In other words, you must build each part before putting a car together and I picture programming to be the same.