Originally Posted by SACoder
I don't know what you mean by "switching between two classes."
Originally Posted by SACoder
Well, regardless of classes or Java or menus or anything else, if you have, say, function a
that calls function b
and function b
calls function a
, that defines a recursion that must have some kind of stopping condition. (I mean, there must be a parameter or other mechanism that a given function uses to decide not to call the other one again. Or some such thing.) As a beginner, I wouldn't want to go there. (I wouldn't necessarily want a not-so-beginner to go there either if he/she had to ask about such things.)
Now, about the terminology: Classes don't "do" anything; so you can't "call" a Class. You can't "call" an Object of a Class either. That's why I don't understand your whole concept of "switching between two classes."
Let's take a simple program. (None of that GUI stuff that hides the big old execution loop with callback functions; none of that thread stuff with multiple clones of processes that seem to be running concurrently; none of that fancy-schmancy multitasking round-robin time-slot scheduling stuff. When I say simple, I mean simple.)
After a certain amount of Java behind-the-scenes startup code, the execution of the user program starts at the beginning of the main()
function of a public class that you have defined.
In very general terms, the main()
function might look like this:
Initialize everything that needs to be initialized.
(Maybe create some objects, maybe open a log file or other I/O
stuff. Etc., etc., etc.)
Set a boolean variable named "running" to true;
while (running == true)
Call a function to display the menu and get user selection.
IF the result returned from menu function indicates that
you are supposed to terminate the program
Set "running" to false.
Call some kind of "worker" function to execute whatever
task was selected by user input
IF the result returned from the selected "worker" function
indicates that you are supposed to terminate the program
Set "running to false.
} // End of big "running" loop
Call a function to clean up everything that needs to be cleaned up.
(Close open files or sockets or whatever...
Write results to a log file if that's what you had set up.
Etc., etc., etc.)
} // End of main()
See? There is no "switching between classes" stuff going on.
The sequence in your main()
function executes specific instructions, one at a time.
If you want the menu()
function to get user input, maybe it returns some value that can be used to call some other function to do whatever task is required. The menu()
function can, perhaps just return an int value (or, maybe an enum data type value).
If user input consists of a number of parameters, then the menu function can return some kind of object or (array or whatever...) that contains all of the information that is required to initiate execution of the task. If, for some reason you decide that the menu()
function will instantiate some other class object, that object can be returned. Etc., etc., etc.
The point is that, after the specific task has been performed, the main loop can go back and display the menu again. Depending on the program, the actual stuff displayed by the menu function may change from loop to loop, depending on what other tasks have been performed (that is, depending on the "state" of the system). If that's the case, then all of the information that menu()
needs can be encapsulated in some kind of object that is used as a parameter.
If the menu function and the various task functions are all in the same class, then it might just be possible to pass information back and forth with object data items of that class, but for programs of any complexity, it may be better to have separate classes, or at least separate objects to convey the information explicitly as parameters.
If there were only one way to organize a program, life would be easy: You could discover the way or invent the way (or you could hire someone to tell you the way), and you would be done.
In the meanwhile, absent such a guru:
I'm not sure that there is a way to "teach" people how to write programs. (If there were, I would sell all my earthly goods and go worship at his/her feet.)
So, rather than getting wrapped up in all of the things that you have seen other programs do, and instead if getting wrapped up in thinking about all of the things that you can imagine that your Real Fun Program will be able to do (eventually), here's a suggestion:
Start with something simple: a menu that lets the user decide whether to terminate the program or to go back and display the menu again. This is going to be part of a loop in main(). You will never (really: never
) call the menu function recursively. You will never (really: never
) call the menu function anywhere except from a single place in the big loop in main(). Period. Full stop.
Once you get the idea of a single big loop in main() under control, well then you can get to the Good Stuff of making a program that actually does something interesting.
Start adding stuff to the menu. As you increase the number of possible tasks, you may have to go back and throw away some previous clever scheme and make something more flexible. That's OK. Really. It's OK. It's an iterative process.