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
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:
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:
and at least get out of static mode.
Does that help?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
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.
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.