DRAFT

Use the new version of the game package $CS680/games5.

1. I have started a forum for this class. Visit it here. Use it from now on to ask questions and post comments.

2. Modify the game package and its drivers so that the "View" part of the Model-View-Controller pattern is decoupled from the Game interface. That means all methods returning Strings (look for them in Move and MoveIterator as well as in Game) belong in a *StringView class extending the interface or abstract class StringView. The StringView class should itself either extend or implement a GameView, since some day there will be a GUIView too. That is, if your game is Foo implements Game then you write FooStringView implementing StringView. The StringView constructor should be passed a Game instance to query for things to be printed and an object to do the printing.

   A GameView object should be an Observer for the Game it is viewing. Whenever a Move is made in the Game the view should update itself.

3. Redo your game port (or another game, as discussed). Put your game in the version of the game package you have just built and write a StringView implementation for it, so that the view is separate from the Game semantics. Pay attention to the comments I made (on your paper or in conference) and read the new version of Easy to see what kinds of things are possible. Be sure to test your game thoroughly.

4. Read the Preface and the first two chapters in Fowler's Refactoring text. Write a few paragraphs about your first impressions of some of what he has to say. I am not asking for a summary - I am interested in your response. Here are some questions you might want to answer - others will occur to you:
   • Have we been refactoring (according to Fowler's definition)?
   • Have we been refactoring correctly?
   • What bad smells have you found in your own code?
   • What connections do you see between refactoring and some of the design patterns we have encountered? (Think particularly about the example in Chapter 1.)
   If you have time, check out Martin Fowler's interview on Slashdot about refactoring. The text won't surprise you once you've read the book, but the threaded discussions following the interviews provide some new insights.

• Source code for revisions to the game package and drivers. When only small parts of some class have changed, just submit a fragment of the file, or highlight the changes so I can find them easily.
• Source code for your ported game.
• Two memos, one for the game package revisions and one for the game port. Be sure each memo discusses testing.
• Your response to Fowler.

From: Ethan Bolker 
To: cs680-1@cs.umb.edu
Subject: evolving StringView design
Date: Thu, 6 Mar 2003 16:21:48 -0500 (EST)

Looking ahead, I think it will be very difficult to separate the
controller from the view (particularly for GUI). And Prof Campbell
concurs, saying that in many contexts "model-view-controller" is
really "model-view" with controls in the view.

So I have rewritten my StringView objects so that they have a Terminal
(for input and output), not just a PrintStream (like System.out, for
output) and will drive user String input as well as output from the
view.

In general, converting the Game interface (or abstract class) to
model-view is hard. Work at doing a thoughtful job rather than a
perfect job. I'd rather have something reasonably well designed rather
than hacked to work. If there are places in your code that smell bad
(see Fowler on refactoring) and you don't know how to fix them, at
least make sure you tell me you are unhappy with them.

We will discuss this hw (and more about threading) next week.