Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
I am pretty new to Swing development and I am running into a problem getting my head around something.
I can write the GUI interface just fine. I can create the action listeners and have the app do what I want. I can even use SwingWorker to run some processing in the background and update the Swing fields as it progresses using the publish and process methods.
The problem I am having is that I do not like having my processing code within the GUI class. I want to try and keep them separate.
Here is a stream-lined example of what I am doing now.
This code borrows heavily from the example in the Sun Tutorial regarding SwingWorker.
The app works fine and does what I am trying to do, but I do not like embedding all of that back end code (StopWatch & StopWatchTask) within the Swing class. I would like to be able to have my extended JFrame class simply draw the interface and manage the events, but place the actual code for the StopWatch in a separate .java files. Separate the Model from the View and Controller and all that.
I did some reading on PropertyChangeListeners and setting up beans to fire PropertyChangeEvents, but I have not been able to make it work. I am willing to proceed down that road, but I wanted to see if this is truly the best option for accomplishing what I want to do. This seems like something that would be fairly common and would have an easier solution.
You have set before you an admirable task, one that I'm trying to learn how to do myself. At this stage what I usually do as a first iteration is separate the model out into its own class, fix errors, and try to add interfaces. Something like this as a first approximation:
That was exactly what I was looking for. Interfaces are one of those things that I tend to not think of, but they come in so handy. I had toyed with the idea of having StopWatchTask take a JFrame as a constructor argument, but still thought it was too connected to the GUI. It never even crossed my mind to use an interface as the argument so that it can be associated with any sort of display class.
I must learn to use interfaces more effectively.
Thank you so much for taking the time to get me on the right track.
OK, here's my next iteration where I try to extract the control out of the view. I'm not so sure about whether this is the correct way to do this or not, so please take it with a grain of salt. Corrections and comments are most welcome!
I cannot say if it is 'correct', but I like it. It separates everything out nicely and keeps each class down to a manageable length. Each class then has a very specific function.
The only minor part that took me a couple reads to get my head around was this part in the StopwMain class.
It seemed cumbersome to declare the view and controller and then have to assign the view to the controller and use two controller methods to configure the view. It is nice having them split out, but at the same time the two classes are so dependent on each other, it results in this kind of required information exchange. I suppose that is the big issue with MVC coding. Trying to separate everything without obfuscating it too much.
Though I blame my slow-moving brain cells more than the code itself for the time it took me to grasp that piece.
I need to read up on Action and AbstractAction. I like that approach better than defining ActionPerformed with an endless if...else construct.
New rule: no elephants at the chess tournament. Tiny ads are still okay.
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth