Programming Question

Hi! I'm trying to build an object oriented system (in Java). There are several classes that provide the functionality of the system and GUI classes that use this functionality. The issue is how will the inner classes notify the GUI when events happen (like finishing reading from the disk, or a new message from the network), since they aren't aware of the existence of GUI classes and cannot call its methods.

I don't see the need for polymorphism except that there could be a general GUI class to which inner classes send messages.
By the way polymorphism is supported in Java. A superclass reference can point to objects of any of its subclasses.

ceptimus said:

Can't you implement a globally callable method within the GUI part that allows the lower level objects to pass messages to the user? Kind of like an alert box in javascript, or a Windows message box.

It's not a perfect solution, I know, as it goes against the object oriented idea.

I would need several such methods to make them global/static like a message box, flashing sign, drawing an image, etc. In this case the inner classes must have knowledge of the top level GUI class. On the other hand these classes can have a pointer/reference to an object of the GUI class to call its methods, but I don't consider this as good practice.

I usually maintain a class wherein i keep a lot of flags (static) ...
i update these flags as an when events occur ... all classes refer this "flag class" periodically and take actions accordingly. This is one way of message passing.

I usually maintain a class wherein i keep a lot of flags (static) ...
i update these flags as an when events occur ... all classes refer this "flag class" periodically and take actions accordingly. This is one way of message passing.

-- AI

No way. Keeping flags would require polling to check their values periodically. But this is costly because of more programming and more time overhead. I'd rather use a bidirectional association between the GUI class and the other classes. I just had thought that the inner classes could generate signals, maybe events or exceptions.

I'm not sure it is the easiest. Maybe if you're just planning on writing a one-off and never touching it again. But if you actually expect to maintain the code then your method will likely end up being a lot of work.

You've basically just created a bunch of global variables and made every event method dependent on them - it sounds pretty fragile. Everything is interconnected, and race conditions could creep in really easily.

You could always do something where GUI classes register themselves with the low level classes, and then when the low-level class does something eventworthy it calls a method on all of the classes registered with it. The low-level events would have to track what's registered with it, but it wouldn't really need to have any understanding of the GUI classes.

You could always do something where GUI classes register themselves with the low level classes, and then when the low-level class does something eventworthy it calls a method on all of the classes registered with it. The low-level events would have to track what's registered with it, but it wouldn't really need to have any understanding of the GUI classes.

Yes, event handling is the optimal scheme. It might have some time overhead, but it is clean design and is very good practice particularly for big systems.