how to seperate stuff into different classes?

[Masha Stekker]

Hi

I am having problems seperating my program into classes rather than just having everything in one class.

The program I am working on reads data from file, places it into an array and then does stuff to it. At the moment I have two classes, one that takes user input, the other does everything else. I would like to be able to seperate the second class into classes that can read values into the array, check through the array and alter it, etc.

I have put a simplified version of my two classes at

http://www.metroweb.co.za/~bmstekker/test/TestMain.java
http://www.metroweb.co.za/~bmstekker/test/ReaderTest.java

If someone could suggest to me how to go about seperating these into neater
classes?

Thanks

[Stan James]

That's an excellent objective, and there are a zillion ways to do it. What are the main steps in your problem description?

* get a number from the user
* read a file
* report on the lines

As a starting point, you can try dividing up classes by those responsibilities. Then your main() method might look like:

int numberOfLines = Prompter.getInt( "Enter the number of lines" );
String[] lines = Reader.readLines( numberOfLines );
Reporter.reportOn( lines );

Can you imagine which parts of your current program go into the three new classes?

Our more advanced readers will notice something right away: I did all this with static methods. The three classes Prompter, Reader and Reporter don't hold any interesting data. That's a sign that I'm thinking in very structured terms instead of object terms. It will still work fine for a first pass for you but with a few more lines of code you can add:

Prompter prompter = new Prompter();
Reader reader = new Reader();
Reporter reporter = new Reporter();

and at least get out of static mode.

Does that help?

[Layne Lund]

I come from a C background and often find procedural programming adequate to solving a problem, especially for programs that don't have a lot of complexity. I start using classes when I see obvious "objects" from the description of the program. From what you have said so far, I don't see any obvious classes that are needed. However, as Stan has shown, you can still come up with some with a little bit of effort.

Layne

[Stan James]

I agree. Good old functional decomposition made me a fine living for years. Those three bullets I started out with could have turned into three methods as well as three classes. But that wasn't the question.

BTW: This topic of how to decide how many classes you have and how they interact expands into the entire field of OO design. It's huge, there's never a "right" answer (though some other peoples' answers are clearly wrong) and you'll struggle with it the rest of your career. The good news is that that's the really fun part.

For a light-hearted look at some of it, see Knight's Principles. If this kind of discussion is interesting, scroll on down to the OO, UML etc. forum.