GUI�s, OO, events and decoupling

(Already posted in java forum before I saw this dedicated forum)
I am constructing a small application that consists of the following principal classes:
A Gui class that includes instances of 3 custom panel classes
An Adapter class that has a reference to the interface of the gui class
A Calculation class that has a reference to the interface of the adapter class
An Application class that sets which gui class and adapter class to use and sets it all in motion
The architecture of the application pleases me (it is closely based on OOPad - an example of using OO in java by a certain Richard Harris)
The Calculation Class includes a method in its constructor to get an array of references to components from the gui classes. These are then �unpacked� and class cast to their type (eg: JSlider etc�)- the new values are then updated [sorry if terminology not always correct � new to programming]
All of this works very well and is cleaner than it sounds when explained. However, I want to have only values being sent out of the GUI (strings, doubles and ints) so that the Calculation Class is not so dependant on the choice of components that are used to construct the gui.
Calculate Class could implement PropertyChangeListener (or some custom ChangeEvent interface) and be added to the gui components to get new values. However, I�m unsure what the cleanest method for updating the gui components with new values would be.
I�m sure that this is a situation that occurs frequently so I�d be interested in suggestions for �best practice�
Cheers
Hugh

I'd be worried by the same thing you are.
The design you have chosen sounds a lot like the "MVC" achitectural pattern except that you have somehow coupled the "view" and "model" parts together, when they should only know about the controller. Take a look at the following two threads from this forum, and see if they help.
http://www.coderanch.com/t/98063/patterns/MVC-gui-basic-questions
http://www.coderanch.com/t/98027/patterns/MVC-pattern-Java-Sample-code

Thanks for the links.
A couple of additional points -
first of all I am unsure of the neccesity of the controller or its exact role (judging by pots MVC questions june 2002 - I'm not the only one) - so for the moment I'm not using a controller (unless of course my adapter class is to some extent fulfilling this role).
secondly in the example given I found the classes quite tightly coupled and was attempting to do something a little looser.
recap:
prog takes input from gui componets, calculates new values and updates gui components (simple!)
my proposed method:
each gui component implements an action listener
that in turn fires an property change event. The property change listner is implemented by the adapter class.
the adapter class then invokes a method on the target class (calculate class) which then calculates results based on new value and informs the adapter that results recalculated
each gui element has registered an interest with the adapter with an interface method that includes a command string
the adapter now notify each gui element with the appropriate new values from the calcute class - the command string is linked to the appropriate get methods in the calculate class.
as far as decoupling goes the calculate class has a refernce to the adapter class interface
the adapter class has a link to the gui class interface
the gui class has direct links to the gui subpanel classes
the app class sets which gui class and adapter class to use and sets it all in motion

I have not yet finished coding this
I would be very pleased to hear any ones views on this
many thanks
Hugh

You might want to take a look at this lecture of mine where I describe an MVC architecture similar to what you want.
Kyle

Kyle
many thanks for the link to your lecture
the iedea of having a controller for each panel was new to me - I was passing everything through the "main" gui class
also I like the methodology of developing (and tetsing) the model before preceding to the guis and controllers
it is different to the method I was thinking of using as events fire methods on other classes and I was thinking of having events fire custom events to notify other classes - and perhaps I was trying to decouple too much (???)
I'll will try an architecture similiar to yours in the first instance
many thanks
Hugh