I am trying to sort out how to organize a problem. I am constrained by the specifications I've been asked to implement.
The goal is to have a table where the user enters data. That data is used to generate a second set of data some of which is displayed in the table and some of which is graphed. The initial conditions for generating the second set of data are to be retrieved from the graph (through getting the position of the cross hairs).
I have a class that implements my table and allows the user to enter data. I was going to have a listener that reran the data generation whenever a cell value changed in this class. Except for the initial conditions, everything needed to generate the data is in the table.
I have a class that implements my graph. It has a scroll bar to modify the initial conditions.
At first I thought I would have a main class that built the panels that the table and graph will sit in. I was going to add an action listener to my graph class that would listen for changes in the table. If it saw the table change, it would re-graph itself. That was before I was told the initial conditions would be set in the graph. I've now gotten rather concerned that everything will get done in the right order. And that my initial idea would even work.
It seems to me I need a class that is responsible for holding the initial conditions and the generated data. I can create a table instance and a graph instance. I can listen for changes to the table entries. I'm not quite sure how to listen to the change in the initial conditions, as currently I make the change by adding a special listener to a JSlider that is defined in the plot code and does all the translation from slider to graph coordinates, which is something I'm using, but did not write. But hopefully, I can have some sort of listener that gets that information. Then this class, when it sees that there is a change, does all the calculations to generate the data and updates the table then tells the graph to redraw.
Since I need to add the table and graph to the gui, I think I need to have all this stuff happen in the class that builds the overall gui. Which seems to put me pretty close to having one great big file that implements the whole gui. I've lost any benefit of encapsulation or having a number of small classes to make maintenance and testing easier.
Am I thinking about this right or could someone suggest a better way to put this all together?
You are actually better off creating a class which takes your data from the command line or console and passes them on to a class which can manipulate or analyse all your data. Get that working. Now you have a model, which stores and manipulates all your data. You also have a sort of control, which passes data to the model and back. Now you can interface that with the keyboard, a text file, a database, a GUI or whatever. Once you have got that working, then think about the GUI as a front-end. Your Listeners, etc., are an enhancement of that “control”.
Joined: Oct 10, 2011
Thanks, I think you are right I need to take a step back and get my data structures straight first. I think I will have two classes. One for the raw data and one for the derived data, I can pass the raw data needed to generate/update the derived data as arguments.
But once I have that done and I have a model for the raw data and a model for the derived data, Then I should create a class that creates instances of my two data models and instances of my two GUI objects. It would then populate the GUI. I would add listeners in this class to listen for changes in the table or the graph and use methods in this class to update the GUI objects.
Now, I think that means that this class, my control class, would need to build the GUI, as it will be making the instances of the GUI objects. Or is that wrong, I should have another class that builds the bulk of the GUI with set methods to add the table and graph panes? Then the controller would make an instance of the main GUI, the table and graph, set the table and graph in the GUI class and itself just focus on listening for what the table and graph tells it and updating them as required?
The table is going to have a ton of events. But I should handle them outside the table class? It's a bit different than things I've done before where the class pretty much takes care of any events within the class.
Jon Swanson wrote:The table is going to have a ton of events. But I should handle them outside the table class? It's a bit different than things I've done before where the class pretty much takes care of any events within the class.
Not being a GUI expert, I don't know; but I'm pretty certain you can subclass ActionEvent. What about a TableChangeEvent? You might even be able to put information about what changed in it. And I'm sure the experts may have better alternatives.
The thing is, as Campbell says: don't worry about it for the moment. It will only distract you. Get a model working that does what you want it to do, and then worry about plugging it into the GUI.
One of the very first books I read about O-O programming contained the following quote:
"When it is not necessary to make a decision, it is necessary not to make a decision." - Lucius Cary, 2nd Viscount Falkland.
and it's a good motto to live by when you're dealing with complex systems.
Bats fly at night, 'cause they aren't we. And if we tried, we'd hit a tree -- Ogden Nash (or should've been).
Articles by Winston can be found here
Joined: Oct 13, 2005
I think you can subclass ActionEvent, but if you are using proper OO design, it is very unusual to need so to do.
Joined: Oct 10, 2011
Well, that is exactly it. I'm trying to sort out how to do the design so that it is a proper OO implementation. As others have suggested, I am in the process of trying to write the definitions for the classes that specify the data models and methods on them. I'm hoping when I have that sorted out, having the GUI control the data entry and retrieval will not seem as non-OO as it does to me at the moment. Stopped reading the Head First Java for the moment and switched over to Head First OOA&D. Though having an internal data table where some info comes from a table widget and other data comes from a graph widget and the computed results go partly in the table and partly in the graph still seems like things are going to be complicated in a way that will make for maintenance head-aches.
You're in the typical situation of a first-time Swing application writer. You understand Java syntax fine, you know how to declare a class and how to call a method, but writing a Swing application does require you to understand object-oriented design reasonably well. If you don't, then your first Swing application is going to be a mess.
Clearly you understand that you're standing on the edge of the cesspit. So studying up on OOD is an excellent plan. And since you have an actual project to work on, you can use that project as a focus for the things you learn in the process. It's going to take you a while, but you are on track.
Even so it's likely that your first Swing application won't be that well-designed. That's just how it is when you try to apply new knowledge for the first time. So be prepared to chuck it out and rework it after a while. At least it shouldn't be a complete disaster.