Re: Design Question

On 12/18/2011 4:13 PM, Novice wrote:


Generally, one wants to "prefer composition to inheritance." That is,
sub-classing (any object, abstract or otherwise(*)) should be considered
after trying to compose a class out of other classes seems unsatisfactory.

((*) However if you must subclass, using an abstract class as the base
class is best.)

In this case, composition might lead you to use two dialogs, each with
different behaviors. Both dialogs might have-a "score" which they
share. This is more MVC, where the dialogs (the view, the V part), are
separate from the model (the M part). Model here means your program
logic (the score from a game) and view means the GUI (or some other
"front end").

class MyInterumScoreDialog extends Dialog {
   private int score;
   ...
}

class MyFinalScoreDialog extends Dialog {
   private int score;
   ...
}

This allows you to have two objects, with different behavior, but which
also share a state (the score). The score here would probably be
injected with a setter method or with the object's constructor. This is
the nice part of composition, that it works well with "dependency
injection."

However, with a bit more reflection, you might decide that the two
dialogs above share a lot of things in common, and only differ slightly
in their behaviors. So you might want to combine them into one object,
if possible. The things that are different are the text they display,
the score itself, the label on the button, and the action taken when the
button is clicked. If these things could be represented in an abstract
way, we'd have a more concise way of expressing what is we want, and an
even more composed object.

This type of operation is so common in GUIs (display a message, collect
a button press) that Swing devotes a whole slew of boilerplate methods
to it.

<http://docs.oracle.com/javase/tutorial/uiswing/components/dialog.html>

Let's see if I can pick one out of that list that seems to fit... Well
the bit on "Customizing the Button Text" seems closest. Unfortunately,
they don't provide a way to abstract the action taken. Here's the basic
code from the tutorial which I've tweaked a bit.

Object[] options = {"OK",};

int n = JOptionPane.showOptionDialog(frame,
     "Your intermediate score is:\n"+score,
     "Intermediate Score",
     JOptionPane.DEFAULT_OPTION,
     JOptionPane.QUESTION_MESSAGE,
     null, //do not use a custom Icon
     options, //the titles of buttons
     options[0]); //default button title

Just FYI, I didn't test or compile that code. Caveat emptor.

So now what do we do about that action? Well we can just test a return
value, and take an appropriate action. We can do this inside a
"controller" (the C part of MVC), which would be some bit of code that
executes in response to a user action. In this case, probably finishing
a level activates the score dialog.

public class MyGame {

   private int score;
   private boolean gameOver; // == "score is final" when true

   ...

   void endLevel() { // called at the end of each level
     // ... other end of level stuff here ...

     // display the score dialog
     if( gameOver ) {
       // display the final score, and exit

       ... JOptionPane.showOptionDialog( ...
       System.exit(0);
     } else { // intermediate score, display and keep going

      ... JOptionPane.showOptionDialog( ...
       // just fall through, final score doesn't return
     }
   }

   ...
}

Note that you'll have to change some of the code from the JOptionPane
exampled I showed for the final block of code. E.g., the text strings
that say "intermediate" should be changed to say "final".

So this seems to separate concerns a bit more to me than inheritance, or
making a class with a special state (which seems to me to mix a bit the
"model" (game code) with the "view" (GUI)) in an odd fashion.

The way it's done here, the GUI is pretty ignorant of what our game's
state is (we just pass it strings, it has no idea what's going on) and
we've eliminated some complexity (that complexity being a special
combined model/GUI class that needs to hold the "final score" state) by
using a standard, built-in class (or method, in this case) that gives us
the behavior we need.

Sometimes, OO makes sense, but sometimes procedural is better.
Especially in "terminal" elements of a design (that is, the leaves or
lowest elements of your design). At some point you have to stop making
objects and just make the code actually do something. When to do that
is a matter of some experience, but also "how easy is this to do?" Once
it's easy enough, just do it.

In this case, I found a standard method that would do what I wanted with
only a little manipulation, so I took that way out. Once my design
reach a point that I could call that method, rather than decompose
further, or make more objects, I just yell "done!" and write the method,
and move on to the next design requirement.