Question

I’m new to designing OO systems. I have a simple Flash Cards app where I’m having trouble figuring out the proper way to architect the system. The application has a simple GUI with a question, answer, and couple buttons. The questions and answers dataset are stored in a Derby embedded database.

Quick Setup:
Database Class – Handles the connect,disconnect, and returns an ArrayList based on a selected filter (currently called by a CardSet object) (the DB class is set up as static)
CardSet Class- Holds the ArrayList being used currently, holds the current Card
Card Class – holds the data for the flash card (question and answer, couple other things)
App Class – Creates the GUI and handles the action events

So here is my question: I want to separate the GUI and the application logic. I am thinking it may be a good case for MVC, but I’m not sure how to really separate it all(never used it) . Does a controller class get created in the main which then launches the GUI and then creates the other classes (in my case, the CardSet). What about access? Do certain things need to be static?

Another question- For handling the GUI events, do you just set it up to call a generic method in the controller class? For instance, the “Next Card” button is clicked, should it just call something like controller.nextCardAction()? Should I try to just use the Observer pattern to let the GUI pull the data?

Sorry for the beginner questions, but this is my first go around at a Java app. Any help would be great. Good links are welcome as well. I have the Head First Design Patterns book, but it just doesn’t have enough real examples for me to fully grasp it for my app.

Answer 1

Here’s a very simple example and discussion that may be helpful.

Where would you read the DB stuff?

I’d expect the model to maintain a reference to the current CardSet, initializing it to some default on construction and refilling it whenever the controller says the user wants a new set. Only the CardSet knows where Cards come from or how to get a new set. In response to user action, the view asks the model for the next or previous card, and updates itself when it hears back from the model to which it is listening.

Don’t confuse the controller with controls: both the view and the controller may manage controls such as buttons. In the example cited, the controller has a reset button, while the view has a panel of game buttons. In your application, the controller might initiate changing sets, while the view has controls to move among the cards in a set.

For reference, the solid lines in the MVC diagram are method invocations and the dotted lines are callbacks to the listener. In the example cited, the Observable and Observer classes provide the update() callback, but the EventListenerList mechanism is also common.