Solving Object-Oriented Java System Issue

  • Context: Java 
  • Thread starter Thread starter ramollari
  • Start date Start date
  • Tags Tags
    Programming
Click For Summary

Discussion Overview

The discussion revolves around the challenges of implementing an object-oriented system in Java, particularly focusing on how inner classes can notify GUI components of events such as disk reads or network messages. The conversation explores various approaches to event handling and communication between classes within the system.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Conceptual clarification

Main Points Raised

  • Some participants suggest implementing a globally callable method within the GUI to allow lower-level objects to pass messages, likening it to alert boxes in JavaScript.
  • Others argue that this approach contradicts object-oriented principles and propose that inner classes should not have direct knowledge of the GUI classes.
  • One participant mentions maintaining a class with static flags for message passing, while another counters that this method requires polling, which can be inefficient.
  • There is a suggestion that GUI classes could register with lower-level classes, allowing the latter to notify all registered classes when an event occurs, promoting a decoupled design.
  • Some participants advocate for event handling as an optimal scheme, acknowledging potential time overhead but emphasizing its clean design and suitability for larger systems.
  • Concerns are raised about the fragility of using global variables and the risk of race conditions in event handling implementations.

Areas of Agreement / Disagreement

Participants express differing views on the best approach to event notification and handling, with no consensus reached on a single optimal method. Some favor event handling, while others highlight the drawbacks of various proposed solutions.

Contextual Notes

Participants note limitations in their proposed methods, such as the need for polling in flag-based systems and the potential complexity of managing event registrations. The discussion reflects a range of assumptions about the design and performance requirements of the system.

ramollari
Messages
433
Reaction score
1
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. :confused:
 
Technology news on Phys.org
Java doesn't have polymorphism like C++, so it's tricky.

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.
 
Hi Ceptimus,

ceptimus said:
Java doesn't have polymorphism like C++, so it's tricky.

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.

-- AI
 
TenaliRaman said:
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 never said my method was fast, but yes definitely its the easiest.

If ur application is speed demanding then there is a way out using swing's invokelater
check this out,
http://forum.java.sun.com/thread.jspa?tstart=15&forumID=424&threadID=566282&trange=15

Hopefully this helps.

-- AI
 
Last edited by a moderator:
TenaliRaman said:
I never said my method was fast, but yes definitely its the easiest.

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.
 
master_coda said:
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.
 
ramollari said:
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.

Well, it shouldn't have a huge time overhead. All you need (at least to start) is a standard handler interface and some simple event dispatching code.
 
  • #10
master_coda said:
I'm not sure it is the easiest. Maybe if you're just planning on writing a one-off and never touching it again.

LOL! You got it! :biggrin:

-- AI
 

Similar threads

Replies
3
Views
4K
Replies
1
Views
2K
  • · Replies 4 ·
Replies
4
Views
4K
  • · Replies 17 ·
Replies
17
Views
2K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 4 ·
Replies
4
Views
6K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 34 ·
2
Replies
34
Views
4K
  • · Replies 32 ·
2
Replies
32
Views
8K