please review design

Newbie & Debugging Questions
#1

I was a bit confused earlier about how to properly connect a GUI to a logic module, and after asking around I was told of 2 common approaches: the MVC model, and a simpler model where you have a Controller that keeps references to your gui objects. I decided to build the latter and was wondering if anyone can look over my simple design and spot anything that I am missing:

Diagram:

GUI:
The GUI has 3 buttons, 2 text areas, and 1 progress bar.

Controller:
The Controller has references to the 2 text areas and the progress bar so that it can update their content.

Core Logic
The Core Logic returns String data, and also calls a method to update the progress bar

The three buttons call methods in the Controller. The Controller then calls the appropriate method in the Core Logic. Core Logic returns data to the controller, which then later updates the proper text area. Core Logic can also call a method in the Controller to update the progress bar, which then calls the method in GUI to update the bar.

#2

I myself use the MVC pattern. I am not sure if the simpler model you describe is really
easier than MVC? Maybe I am missing something?

To answer your question: yes, I think how you describe it is ok. (I never heard about the
“controller” pattern, so I might be wrong).

However, I would advice you to use MVC. The only difference is the following:
The “Core Logic” updates the “Controller” & then the “Controller” updates the “GUI”.
In MVC, the “Core Logic” directly updates the “GUI”.

I don’t quite see why the “Core Logic” has to update the “Controller”, it’s one more method
you will need to implement which does not do anything more than just update the “GUI”.
MVC would be shorter in that case.

Also, look at the diagrams, MVC and your pattern are pretty much the same:
http://www.enode.com/x/markup/tutorial/mvc.html

#3

Yeah I changed that so the Core Logic just updates the Controller which then updates the value of the registered GUI component. The reason for this is so the Core Logic does not hold any refrences to the GUI, just the Controller. Thanks for the feedback.

#4

where are you going to with this design?

if I hear what you say, it has some aspects of the mediator-pattern with a twist of mvc. whats the problem and how is this gonna help?

#5

My intial confusion was just how to properly attach a GUI to a Core Logic module that I built. I did want the ability to extensively modify the GUI or plug in a different one, without modding the Core Logic. Also, the Core Logic was suppose to return data to the GUI. I kind of figured that having the Core Logic hold a ref to the GUI and the GUI holding a ref to the Core Logic was bad design.

#6

Yes, that’s good! Whatever you do for the “Core Logic”, keep it separate from the GUI. The “Core Logic” should know nothing about the GUI.

However, the GUI holds an instance of the “Core Logic”. You can update the GUI in two ways:
-Poll the “Core Logic” e.g. every 50ms and update the view if something changed (->not so good lot of overhead)
-Push method:

  1. Add to “Core Logic”:
    addChangeListener(…)
    removeChangeListener(…)
    fireChange(…)
    Changes are sent from the “Core Logic” to all registered listeners.

  2. Register the GUI as listener for changes in the “Core Logic”

  3. and 2. keep GUI and “core logic” separate: MVC pattern

#7

to what extend? change the viewtype? annaloge meter or other graphical representation vs plain number. Change the look? colors,design of the graphical representation(older looking meter) Placement? gobal as well as how components are lined out how much power does the user need?

mind you for data to be displayed there has to be a reference somehow, the aspect is more if its a loose reference or a fixed one. also to implent multiplicity your gonna need 2 classes

#8

Yes the MVC pattern is definatly the way to go, I am seeing that more and more now.

#9

Cool definatly will give the Listener approach a go