Disconnect between the model and view

One of the things that I implemented with the Sudoku game was a disconnect between the model and the view. I provided a representation of a Sudoku game that knows nothing of user interface. It knows about cells and boxes and numbers; it also knows if any given cell is considered valid. It knows nothing about what colour should be used to draw a cell, how thick the lines should be, or anything else that has anything to do with drawing.

To help with the drawing part, and to avoid having to continually recompute position information for individual cells, I introduced the notion of a CellDrawer that does know about colours, and line thickness, and such. It also knows–in absolute coordinates–where to draw the cell. This class is part of the user interface code.

I set up the Sudoku board so that it can be observed. Interested parties, like a user interface, can register event listeners that are triggered when a change occurs on the board. I use the listeners consistently. When the user clicks on the board or types a key, the user interface translates that operation into a command that’s passed to the Sudoko board. The command is along the lines of “set the value of the cell at position (5,4) to 7″ (position is the relative position of a cell, not a screen co-ordinate). The board makes the necessary modifications and fires an event to inform interested parties of the change. The user interface is one of the interested parties, and when it receives the event it redraws the board. I could have done this a lot simpler: when the user clicks or types a key, change the board and then get the user interface to redraw. Why not just do this? Why all the extra event stuff?

Well… Chris answered this question pretty well. In a few minutes on a plane, Chris added an ECF component to the game: he made the Sudoku game multi-player. He did it without interacting with the user interface, he just worked directly with the model. When the remote user makes a change, a message is sent. When that message is received, the model is modified which causes an event to be triggered resulting in the user interface updating. Pretty cool. And, a fine example of extending a system in a way that the original author had never considered.

I use the event in other places as well. The solver included with the implementation modify the model which then triggers an update of the user interface. The solvers know nothing about the user interface.

At some point, I’ll probably add a couple more views to the game. An obvious view might show some statistics: how many cells are left, how long as the game been going, how many times has a particular cell been changed, etc. This view will also just register itself to receive changed events from the board and update itself whenever those events are triggered. My main user interface will not have to know anything about this new view and so will be totally decoupled; but it will appear to the user to be tightly integrated. Very cool.

This relationship is described by the Observer Pattern. It’s used extensively throughout the Eclipse code (including SWT) and all over the place in Java. Heck, we even used it in (wait for it, Denis…) Smalltalk! It’s a pretty powerful mechanism that may require a little bit of work up front, but sure makes building applications a lot easier.

About these ads
This entry was posted in Uncategorized. Bookmark the permalink.

9 Responses to Disconnect between the model and view

  1. Jeroen says:

    Uhm, perhaps a dumb question on my part. But is the Sudoko App in any way opensource. :DI followed a link to Chris’ site and he had a bugzilla link with a patch in it. Would be nice to have a smaller example to mess with.These are just a bit overwhelming at first glance: http://www.eclipse.org/community/rcpos.php ;)

  2. Jeroen says:

    I already have an RCP chat client though! Guess which book. ;)

  3. Wayne says:

    It is open source and you can download the source by importing this project set:http://www.eclipse.org/evangelism/samples/sudoku/sudoku.psf

  4. Jeroen says:

    Tnx a million…I clicked through it a bit and have already seen some very helpful and interesting things.

  5. Jeroen says:

    Am I correct that the current implementation does not have a Sudoku generator yet?I’ll look into patching this into the generator plug-in.http://www.klepphelmer.com/Sudoku/DLXEngine.javaAnd that’s not something I’ve written.

  6. Wayne says:

    In fact, there are two generators. They should be included. Unless something horribly, horribly wrong happened.

  7. Jeroen says:

    I’ll look into it. If I have any findings, I’ll see if I can file a bugzilla report.

  8. Jeroen says:

    It works, my bad. Really simple too.Selecting “Run as…” on the application plugin results in a run configuration with only the default plugins enabled. Enabling the non-required plugins (like the generator plug-ins) was something I failed to do. :)One of those gotcha’s. :) Now it works like a charm and I can play Sudoku till I drop.

  9. Pingback: Ladislao Shute

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s