Switching between classes

Hey guys,

I need help with the concept of switching between two classes. However it is not that simple...

Here is an example that can illustrate my problem.

Say you have a Menu class and from here you set all of menu's variable to null and call initiated that code [new Class(Parameters);].

In the Class class you then wish to go to the Menu class and call the initiated code [new Menu(Parameters);].

This creates a problem in that you have a Menu class running a Class class running a Menu class. Is there anyway of solving this problem?

Thanks

Ok, I understand that you are saying there is a sort of initiating loop between Menu and Class, but I think the more broad question is what exactly these constructors are going to be doing and why you are doing this. I suspect there is a far better way of doing what you are trying, but we won't know until we know what you're actually doing.

This is a pretty much kind of design issue. When you have two class and you want them to interact and if you want to switch between them. I would recommend using a third class that will act like a moderator between these two class. You can switch between the two classes from the third class.
In you example above.. If you have Menu Class and Class class. You should create a third class lets say Main class where you make interaction between them. This is a standard way of solving such kind of problem. You could actually interact between the two classes. But it is not a good programming practice from design perspective. It will be hard to maintain and update code in future. So you have to create a third class to make interaction between them.

What is the proposed purpose of the menu class?

Quote:

---

Originally Posted by SACoder

...
I need help with the concept of switching between two classes.

---

I don't know what you mean by "switching between two classes."

Quote:

---

Originally Posted by SACoder

Here is an example that can illustrate my problem.

---

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.)

Anyhow...

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:

Code :

---

main()
{
  Setup:
    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;
 
  Loop:
    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
        THEN
           Set "running" to false.
        ELSE
            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
            THEN
               Set "running to false.
            END IF
        END IF
    } // End of big "running" loop
 
  Cleanup:
    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.

Bottom line:
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:

[/begin 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.
[/end Suggestion]


Cheers!

Z