Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10856 > unrolled thread

Design Question

Back to article view | Back to comp.lang.java.programmer

Contents

  Design Question Novice <novice@example..com> - 2011-12-19 00:13 +0000
    Re: Design Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-18 19:24 -0500
      Re: Design Question ilAn <idonot@wantspam.net> - 2011-12-20 16:47 +0200
        Re: Design Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-20 10:39 -0500
    Re: Design Question markspace <-@.> - 2011-12-18 19:23 -0800
      Re: Design Question Novice <novice@example..com> - 2011-12-19 13:26 +0000
      Re: Design Question Novice <novice@example..com> - 2011-12-19 13:28 +0000
    Re: Design Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-19 07:16 -0400
      Re: Design Question Novice <novice@example..com> - 2011-12-19 13:49 +0000
        Re: Design Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-19 22:22 +0000
          Re: Design Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-19 20:13 -0400
            Re: Design Question Lew <lewbloch@gmail.com> - 2011-12-20 07:37 -0800
              Re: Design Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-20 10:42 -0500
                Re: Design Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-20 17:46 -0400
          Re: Design Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-20 20:40 +0000
    Re: Design Question Novice <novice@example..com> - 2011-12-19 13:34 +0000
    Re: Design Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-19 06:25 -0800
    Re: Design Question Gene Wirchenko <genew@ocis.net> - 2011-12-19 11:38 -0800
      Re: Design Question Lew <lewbloch@gmail.com> - 2011-12-20 07:42 -0800
        Re: Design Question Gene Wirchenko <genew@ocis.net> - 2011-12-20 11:51 -0800
          Re: Design Question soulspirit@gmail.com - 2011-12-20 14:55 -0800
            Re: Design Question Gene Wirchenko <genew@ocis.net> - 2011-12-20 15:25 -0800
              Re: Design Question soulspirit@gmail.com - 2011-12-21 01:11 -0800
                Re: Design Question Gene Wirchenko <genew@ocis.net> - 2011-12-21 11:08 -0800
                  Re: Design Question soulspirit@gmail.com - 2011-12-21 15:27 -0800
                    Re: Design Question Gene Wirchenko <genew@ocis.net> - 2011-12-21 18:06 -0800

Page 1 of 2  [1] 2  Next page →

#10856 — Design Question

I am trying to make sure I have the right idea in designing a class for a 
game I am writing.

The game is capable of showing the score either during the game or at the 
end. In both cases, I simply display a dialog showing the score. If the 
game isn't over yet, I entitle the dialog "Interim Score". If the game is 
finished, I entitle the dialog "Final Score". When the player is given the 
interim score, the button at the bottom says "Quit" and he is returned to 
the game when he presses it. When the player is given the final score, the 
button at the bottom says "Exit" and the game itself ends when he presses 
it. 

At the moment, I have a single class that gets invoked to show both the 
interim score and the final score. That class is passed a boolean which 
indicates if it is an interim score or a final one. Based on that boolean, 
the title of the dialog is set appropriately and the button text is set to 
either Quit or Exit. The actionPerformed() doesn't change: Quit causes a 
dispose() and Exit causes a System.exit(0).

While the dialog is simple and works just fine, I suspect I'm violating 
some OO principles by making the behavior of the class change depending on 
what kind of score is being shown. 

Am I right in thinking that I should actually have an abstract class, maybe 
called AbstractScore, and that it should have two subclasses, Interim Score 
and FinalScore? AbstractScore could have all of the "common code" in it 
while InterimScore and FinalScore could each do the stuff that was unique 
to itself, like setting the Title appropriately, setting the text of the 
button, and reacting to the appropriate button in actionPerformed(). In 
other words, the actionPerformed() in InterimScore would only react to Quit 
while the actionPerformed() in FinalScore would only react to Exit. Then, 
my game should instantiate InterimScore during the game and FinalScore when 
the user wants to end the game. 

Or is there a better way?  
-- 
Novice

[toc] | [next] | [standalone]

#10857

On 12/18/2011 7:13 PM, Novice wrote:
> I am trying to make sure I have the right idea in designing a class for a
> game I am writing.
>
> The game is capable of showing the score either during the game or at the
> end. In both cases, I simply display a dialog showing the score. If the
> game isn't over yet, I entitle the dialog "Interim Score". If the game is
> finished, I entitle the dialog "Final Score". When the player is given the
> interim score, the button at the bottom says "Quit" and he is returned to
> the game when he presses it. When the player is given the final score, the
> button at the bottom says "Exit" and the game itself ends when he presses
> it.
>
> At the moment, I have a single class that gets invoked to show both the
> interim score and the final score. That class is passed a boolean which
> indicates if it is an interim score or a final one. Based on that boolean,
> the title of the dialog is set appropriately and the button text is set to
> either Quit or Exit. The actionPerformed() doesn't change: Quit causes a
> dispose() and Exit causes a System.exit(0).
>
> While the dialog is simple and works just fine, I suspect I'm violating
> some OO principles by making the behavior of the class change depending on
> what kind of score is being shown.
>
> Am I right in thinking that I should actually have an abstract class, maybe
> called AbstractScore, and that it should have two subclasses, Interim Score
> and FinalScore? AbstractScore could have all of the "common code" in it
> while InterimScore and FinalScore could each do the stuff that was unique
> to itself, like setting the Title appropriately, setting the text of the
> button, and reacting to the appropriate button in actionPerformed(). In
> other words, the actionPerformed() in InterimScore would only react to Quit
> while the actionPerformed() in FinalScore would only react to Exit. Then,
> my game should instantiate InterimScore during the game and FinalScore when
> the user wants to end the game.
>
> Or is there a better way?

The abstract class with two sub classes must be the OO way.

Arne

[toc] | [prev] | [next] | [standalone]

#10895

Arne Vajhøj <arne@vajhoej.dk> writes:

> On 12/18/2011 7:13 PM, Novice wrote:
>>
>> Am I right in thinking that I should actually have an abstract class, maybe
>> called AbstractScore, and that it should have two subclasses, Interim Score
>> and FinalScore? AbstractScore could have all of the "common code" in it
>> while InterimScore and FinalScore could each do the stuff that was unique
>> to itself, like setting the Title appropriately, setting the text of the
>> button, and reacting to the appropriate button in actionPerformed(). In
>> other words, the actionPerformed() in InterimScore would only react to Quit
>> while the actionPerformed() in FinalScore would only react to Exit. Then,
>> my game should instantiate InterimScore during the game and FinalScore when
>> the user wants to end the game.
>>
>> Or is there a better way?
>
> The abstract class with two sub classes must be the OO way.

Or you could consider the user of an interface, two classes that
implement that interface - and a factory class that returns the correct
one. You should pass some kind of object to the factory class, maybe in
the constructor; from which it can work out what type of class to
return. (Maybe the Game itself as a class/interface.)

This would allow you to add other types of class that implement the
interface for scenarios you have not yet imagined.

--
ilAn

[toc] | [prev] | [next] | [standalone]

#10900

On 12/20/2011 9:47 AM, ilAn wrote:
> Arne Vajhøj<arne@vajhoej.dk>  writes:
>> On 12/18/2011 7:13 PM, Novice wrote:
>>> Am I right in thinking that I should actually have an abstract class, maybe
>>> called AbstractScore, and that it should have two subclasses, Interim Score
>>> and FinalScore? AbstractScore could have all of the "common code" in it
>>> while InterimScore and FinalScore could each do the stuff that was unique
>>> to itself, like setting the Title appropriately, setting the text of the
>>> button, and reacting to the appropriate button in actionPerformed(). In
>>> other words, the actionPerformed() in InterimScore would only react to Quit
>>> while the actionPerformed() in FinalScore would only react to Exit. Then,
>>> my game should instantiate InterimScore during the game and FinalScore when
>>> the user wants to end the game.
>>>
>>> Or is there a better way?
>>
>> The abstract class with two sub classes must be the OO way.
>
> Or you could consider the user of an interface, two classes that
> implement that interface - and a factory class that returns the correct
> one. You should pass some kind of object to the factory class, maybe in
> the constructor; from which it can work out what type of class to
> return. (Maybe the Game itself as a class/interface.)
>
> This would allow you to add other types of class that implement the
> interface for scenarios you have not yet imagined.

He said "common code".

Arne

[toc] | [prev] | [next] | [standalone]

#10860

On 12/18/2011 4:13 PM, Novice wrote:
> Am I right in thinking that I should actually have an abstract class, maybe
> called AbstractScore, and that it should have two subclasses,

> Or is there a better way?


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.

[toc] | [prev] | [next] | [standalone]

#10868

markspace <-@.> wrote in news:jcmaoa$rpc$1@dont-email.me:

> On 12/18/2011 4:13 PM, Novice wrote:
>> Am I right in thinking that I should actually have an abstract class,
>> maybe called AbstractScore, and that it should have two subclasses,
> 
>> Or is there a better way?
> 
> 
> 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.
> 

Thanks VERY much markspace for taking me through that thought process and 
helping me understanding what a more experienced designer would do in 
this situation. 

As it turns out, I thought of a better way to handle the score as I was 
composing my question - to simply show the current score on the main game 
window itself throughout the game rather than displaying a dialog on 
request - but I kept writing the question anyway to get a handle on the 
thought process that I should be going through with respect to the two 
very similar dialogs. Therefore, my effort in asking the question and 
yours in answering it were NOT wasted and I've learned a better way to 
think of these matters.

So thanks again, markspace!

--
Rhino



-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10869

markspace <-@.> wrote in news:jcmaoa$rpc$1@dont-email.me:

> On 12/18/2011 4:13 PM, Novice wrote:
>> Am I right in thinking that I should actually have an abstract class,
>> maybe called AbstractScore, and that it should have two subclasses,
> 
>> Or is there a better way?
> 
> 
> 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.
> 

Thanks VERY much markspace for taking me through that thought process and 
helping me understanding what a more experienced designer would do in 
this situation. 

As it turns out, I thought of a better way to handle the score as I was 
composing my question - to simply show the current score on the main game 
window itself throughout the game rather than displaying a dialog on 
request - but I kept writing the question anyway to get a handle on the 
thought process that I should be going through with respect to the two 
very similar dialogs. Therefore, my effort in asking the question and 
yours in answering it were NOT wasted and I've learned a better way to 
think of these matters.

So thanks again, markspace!

-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10865

On 11-12-18 08:13 PM, Novice wrote:
> I am trying to make sure I have the right idea in designing a class for a 
> game I am writing.
> 
> The game is capable of showing the score either during the game or at the 
> end. In both cases, I simply display a dialog showing the score. If the 
> game isn't over yet, I entitle the dialog "Interim Score". If the game is 
> finished, I entitle the dialog "Final Score". When the player is given the 
> interim score, the button at the bottom says "Quit" and he is returned to 
> the game when he presses it. When the player is given the final score, the 
> button at the bottom says "Exit" and the game itself ends when he presses 
> it. 
> 
> At the moment, I have a single class that gets invoked to show both the 
> interim score and the final score. That class is passed a boolean which 
> indicates if it is an interim score or a final one. Based on that boolean, 
> the title of the dialog is set appropriately and the button text is set to 
> either Quit or Exit. The actionPerformed() doesn't change: Quit causes a 
> dispose() and Exit causes a System.exit(0).
> 
> While the dialog is simple and works just fine, I suspect I'm violating 
> some OO principles by making the behavior of the class change depending on 
> what kind of score is being shown. 
> 
> Am I right in thinking that I should actually have an abstract class, maybe 
> called AbstractScore, and that it should have two subclasses, Interim Score 
> and FinalScore? AbstractScore could have all of the "common code" in it 
> while InterimScore and FinalScore could each do the stuff that was unique 
> to itself, like setting the Title appropriately, setting the text of the 
> button, and reacting to the appropriate button in actionPerformed(). In 
> other words, the actionPerformed() in InterimScore would only react to Quit 
> while the actionPerformed() in FinalScore would only react to Exit. Then, 
> my game should instantiate InterimScore during the game and FinalScore when 
> the user wants to end the game. 
> 
> Or is there a better way?  

I'm with Stefan when he says that an informational dialog of this type
is annoying, and that being able to quit the entire application from the
dialog (if it is a final score) is unusual. I'm with markspace when he
says "At some point you have to stop making objects and just make the
code actually do something" and also with respect to his comments about
separation of concerns.

Microsoft has an excellent checklist at
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx. I
direct your attention to the section "Is this the right user
interface?", and in particular the bullets "Would it be preferable to
use in-place UI?" and "For task flows, would it be preferable to use
another page?".

Better UI choices would avoid this entire problem.

As an aside, "Quit" and "Exit" mean the same thing. "Quit" in your
original terminology is more appropriately "OK".

As another aside, why the distinction between an interim score and a
final score...anywhere? I'd just have the score as a non-interesting
number. Are you saying that the user cannot quit at any time?

For a different situation - one that truly rates it - your observations
regrading using an abstract class with common functionality, and
overridden specialized methods in the derived classes, are on point.

AHS

[toc] | [prev] | [next] | [standalone]

#10872

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote in
news:p2FHq.27831$2e7.8589@newsfe18.iad: 

> On 11-12-18 08:13 PM, Novice wrote:
>> I am trying to make sure I have the right idea in designing a class
>> for a game I am writing.
>> 
>> The game is capable of showing the score either during the game or at
>> the end. In both cases, I simply display a dialog showing the score.
>> If the game isn't over yet, I entitle the dialog "Interim Score". If
>> the game is finished, I entitle the dialog "Final Score". When the
>> player is given the interim score, the button at the bottom says
>> "Quit" and he is returned to the game when he presses it. When the
>> player is given the final score, the button at the bottom says "Exit"
>> and the game itself ends when he presses it. 
>> 
>> At the moment, I have a single class that gets invoked to show both
>> the interim score and the final score. That class is passed a boolean
>> which indicates if it is an interim score or a final one. Based on
>> that boolean, the title of the dialog is set appropriately and the
>> button text is set to either Quit or Exit. The actionPerformed()
>> doesn't change: Quit causes a dispose() and Exit causes a
>> System.exit(0). 
>> 
>> While the dialog is simple and works just fine, I suspect I'm
>> violating some OO principles by making the behavior of the class
>> change depending on what kind of score is being shown. 
>> 
>> Am I right in thinking that I should actually have an abstract class,
>> maybe called AbstractScore, and that it should have two subclasses,
>> Interim Score and FinalScore? AbstractScore could have all of the
>> "common code" in it while InterimScore and FinalScore could each do
>> the stuff that was unique to itself, like setting the Title
>> appropriately, setting the text of the button, and reacting to the
>> appropriate button in actionPerformed(). In other words, the
>> actionPerformed() in InterimScore would only react to Quit while the
>> actionPerformed() in FinalScore would only react to Exit. Then, my
>> game should instantiate InterimScore during the game and FinalScore
>> when the user wants to end the game. 
>> 
>> Or is there a better way?  
> 
> I'm with Stefan when he says that an informational dialog of this type
> is annoying, and that being able to quit the entire application from
> the dialog (if it is a final score) is unusual. I'm with markspace
> when he says "At some point you have to stop making objects and just
> make the code actually do something" and also with respect to his
> comments about separation of concerns.
> 
I realized as I was composing the post that it made more sense to simply 
show the current score on the main game window all the time than to make 
the player ask for it and then pop up a dialog to show it to him. 

But the core of the question still seemed like one that would come up 
regularly and not necessarily be resolved with a change to the GUI so I 
finished the question for the sake of future situations that wouldn't 
necessarily be answered so simply.

> Microsoft has an excellent checklist at
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx.
> I direct your attention to the section "Is this the right user
> interface?", and in particular the bullets "Would it be preferable to
> use in-place UI?" and "For task flows, would it be preferable to use
> another page?".
> 
> Better UI choices would avoid this entire problem.
>
Agreed. This is actually an older program that I am bringing up to date 
and I'm trying to be truer to OO principles in it than I was in the 
original coding. I thought of doing the abstract class and the two 
sibling subclasses but wanted to make sure that was the right OO 
approach. But the whole question disappears entirely if I put the score 
on the main game window and keep it updated as the score changes.  
 
> As an aside, "Quit" and "Exit" mean the same thing. "Quit" in your
> original terminology is more appropriately "OK".
>
Agreed. When I first wrote the program, I had the impression that "Quit" 
meant "dismiss the window but otherwise continue with the program" while 
"Exit" meant "I'm done with the program and want to end it.". I simply 
got that wrong. Thanks to you and Stefan for catching that. Now I need to 
go back over other old programs and replace "quit" with "ok".

> As another aside, why the distinction between an interim score and a
> final score...anywhere? I'd just have the score as a non-interesting
> number. Are you saying that the user cannot quit at any time?
>
The distinction is that the final score gets shown after all turns are 
complete while the interim score does not reflect the results of the 
current turn. Also, the final score is shown automatically as the player 
is exiting the game while the interim score is shown "on demand" via the 
player clicking a "Score" button. 

But those distinctions essentially evaporate now that I'm moving the 
score to the main game window. 

> For a different situation - one that truly rates it - your
> observations regrading using an abstract class with common
> functionality, and overridden specialized methods in the derived
> classes, are on point. 
> 
Good! Thanks for helping me make sure I was doing that reasoning 
correctly, Arved.


-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10884

On Mon, 19 Dec 2011 13:49:04 +0000, Novice wrote:

> Agreed. This is actually an older program that I am bringing up to date
> and I'm trying to be truer to OO principles in it than I was in the
> original coding. I thought of doing the abstract class and the two
> sibling subclasses but wanted to make sure that was the right OO
> approach. But the whole question disappears entirely if I put the score
> on the main game window and keep it updated as the score changes.
>
I'd normally take a somewhat different approach: since this game is all 
about the user interacting with a graphical front end, I'd design the GUI 
first and think about the class structure only when happy with that. 

IMO the design of the GUI is extremely important and deserves a lot of 
care because, if its poor as many GUI designs are, the application will 
suffer because people are going to be less enthusiastic about using it 
regardless of how good the design and code behind it may be.

In this case I agree with everybody else as far as the score goes: its an 
integral part of the game so it belongs on the main window as a permanent 
display field. If the game has a status display bar, that's where it 
belongs. Since most GUI programs have a menu bar containing Help and 
About operations, I'd p-rovide one for the game too and put an 'Exit' 
button in the conventional place in a drop-down 'File' menu, right under 
a 'Save game state' item (if you need one), where it could be used at any 
time.

I'd consider using a JOptionPane dialog that only gets shown at the end 
of the game when it pops up to display 'Exit' and 'Another game' buttons 
so the user can decide whether to exit or start another game. Needless to 
say, it needs to be positioned so it doesn't hide the final score.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#10888

On 11-12-19 06:22 PM, Martin Gregorie wrote:
> On Mon, 19 Dec 2011 13:49:04 +0000, Novice wrote:
> 
>> Agreed. This is actually an older program that I am bringing up to date
>> and I'm trying to be truer to OO principles in it than I was in the
>> original coding. I thought of doing the abstract class and the two
>> sibling subclasses but wanted to make sure that was the right OO
>> approach. But the whole question disappears entirely if I put the score
>> on the main game window and keep it updated as the score changes.
>>
> I'd normally take a somewhat different approach: since this game is all 
> about the user interacting with a graphical front end, I'd design the GUI 
> first and think about the class structure only when happy with that. 
> 
> IMO the design of the GUI is extremely important and deserves a lot of 
> care because, if its poor as many GUI designs are, the application will 
> suffer because people are going to be less enthusiastic about using it 
> regardless of how good the design and code behind it may be.
[ SNIP ]

I wouldn't argue with that much at all. I'll elaborate a bit on how I
really like to see things work so you can see the differences. :-)

Over the years I've seen that workflow and presentation in UIs
(navigation, what's visible and what's not, what's enabled and what's
not, how are the pages broken out, etc etc) end up being so important
for most clients in UAT that it's best to get all that worked out in
requirements.

If I can convince people to go along with the idea I try to introduce as
much storyboarding, wireframe and prototyping as I can. Which is usually
not much, because in decades of software development I've run across a
lot of negative attitudes about all of that. I'm not sure why, because
invariably the folks who do none of that end up with big surprises
during acceptance testing.

I also try to get business eyes onto working interfaces as early as
possible during development. In my experience the more often, and the
earlier, that users see the UI and experience the workflow, the more
likely you are to have smooth UAT.

Having said all that, when technical requirements are completed, I don't
normally do detailed design or implementation on the UI first. I've done
the due diligence to establish exactly what that UI should look like, so
I prepare the business logic first. There is a lot of iterative work in
any case, so it's not accurate to say that all of the lower layers get
completely coded up, and only then do I do consider UI work. But I do
have a bias for ensuring that the business logic is designed and coded
earlier than the presentation.

I also aim for very early "happy paths" that exercise all critical or
somewhat nebulous technologies. This may not often be required, not if
everything you're using is tried and true. But if something is dubious
and/or critical, and there's not been time for a pre-requirements Proof
Of Technology (POT) mini-project, I try to get such a "happy path" POT
in as soon as possible. This can often require doing UI work quite early on.

I don't think that any experienced practitioner would discount the
importance of the UI. You might have arguments about how pretty you make
it, but IMO that's what trained graphics designers are for. I used to
work for one web app shop that had a trained graphics designer on staff,
and this guy was cerebral. He didn't have patience for the superficial
special-effects kiddies either; it was all "form follows function" and
human interface guidelines and minimalism. He was well ahead of his
time, this was just over a decade ago.

AHS

[toc] | [prev] | [next] | [standalone]

#10899

Arved Sandstrom wrote:
> I don't think that any experienced practitioner would discount the
> importance of the UI. You might have arguments about how pretty you make
> it, but IMO that's what trained graphics designers are for. I used to
> work for one web app shop that had a trained graphics designer on staff,
> and this guy was cerebral. He didn't have patience for the superficial
> special-effects kiddies either; it was all "form follows function" and
> human interface guidelines and minimalism. He was well ahead of his
> time, this was just over a decade ago.

Really?  "Form follows function" is less than a decade old?

And yet I read the first edition of 
http://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/0470084111
well over a decade ago.

Hm.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10901

On 12/20/2011 10:37 AM, Lew wrote:
> Arved Sandstrom wrote:
>> I don't think that any experienced practitioner would discount the
>> importance of the UI. You might have arguments about how pretty you make
>> it, but IMO that's what trained graphics designers are for. I used to
>> work for one web app shop that had a trained graphics designer on staff,
>> and this guy was cerebral. He didn't have patience for the superficial
>> special-effects kiddies either; it was all "form follows function" and
>> human interface guidelines and minimalism. He was well ahead of his
>> time, this was just over a decade ago.
>
> Really?  "Form follows function" is less than a decade old?
>
> And yet I read the first edition of
> http://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/0470084111
> well over a decade ago.
>
> Hm.

I don't think "doing X, Y and Z being ahead of time 10 years ago"
does imply that none of X, Y and Z were known 10 years ago.

Arne

[toc] | [prev] | [next] | [standalone]

#10914

On 11-12-20 11:42 AM, Arne Vajhøj wrote:
> On 12/20/2011 10:37 AM, Lew wrote:
>> Arved Sandstrom wrote:
>>> I don't think that any experienced practitioner would discount the
>>> importance of the UI. You might have arguments about how pretty you make
>>> it, but IMO that's what trained graphics designers are for. I used to
>>> work for one web app shop that had a trained graphics designer on staff,
>>> and this guy was cerebral. He didn't have patience for the superficial
>>> special-effects kiddies either; it was all "form follows function" and
>>> human interface guidelines and minimalism. He was well ahead of his
>>> time, this was just over a decade ago.
>>
>> Really?  "Form follows function" is less than a decade old?
>>
>> And yet I read the first edition of
>> http://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/0470084111
>>
>> well over a decade ago.
>>
>> Hm.
> 
> I don't think "doing X, Y and Z being ahead of time 10 years ago"
> does imply that none of X, Y and Z were known 10 years ago.
> 
> Arne
> 
Thank you, Arne.

AHS

[toc] | [prev] | [next] | [standalone]

#10913

On Tue, 20 Dec 2011 04:10:53 +0000, Stefan Ram wrote:

>   However, you do not necessarily need to get it right right from the
>   start. Instead you can write the GUI code to be maintainable and then
>   improve the GUI according to your own observations and user feedback.
>
True enough, but you at least need to fit the design and dialogue type to 
the type of user and the way the system will be used. Even after all 
these years I think there's a lot of value in James Martin's "Design of 
Man-Computer Dialogs". 

I agree with Arved about the iniquities of mixed mouse/keyboard dialogues 
and, for text entry type applications such as you might write in the past 
with a 4GL, find that straight keyboarding without forcing the user to 
touch the mouse makes for much faster interactions.
  
>>I'd consider using a JOptionPane dialog that only gets shown at the end
>>of the game when it pops up to display 'Exit' and 'Another game' buttons
>>so the user can decide whether to exit or start another game. Needless
>>to say, it needs to be positioned so it doesn't hide the final score.
> 
>   In this case, I'd prefer the program to just wait (without opening a
>   dialog). The user than is free to issue commands, including »exit« or
>   »another game«, from the program menu.
>
Yes I wondered about that as I wrote it, but was thinking of it as a 
screen area that shows something along the lines of "Yay, you won! 999 is 
the highest score EVAH!" and then asked "Wanna play again?" which could 
be implemented as a Y/N entry box or a pair of buttons at the designer's 
choice. I was not thinking of a pop-up as such.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#10871

ram@zedat.fu-berlin.de (Stefan Ram) wrote in
news:Score-20111219050746@ram.dialup.fu-berlin.de: 

> Novice <novice@example..com> writes:
>>The game is capable of showing the score either during the game or at
>>the end. In both cases, I simply display a dialog showing the score.
> 
>   As a user I am annoyed by such informational dialogs,
>   because they hide something and require my action. 
>   The score should better be displayed as a text field
>   somewhere in the main game window.
> 
Good point, Stefan. As it happens, I had the same thought as I was 
composing the question and realized that I should simply be showing the 
current score right on the game window itself, not making the player 
request the score whenever he wants it. 

But the basic issue of how to handle an issue like this still seemed like 
an interesting one so I finished the question just to learn more about 
the thought process that should be used in resolving this sort of 
question.
 
>>finished, I entitle the dialog "Final Score". When the player is given
>>the interim score, the button at the bottom says "Quit" and he is
>>returned to 
> 
>  »Quit« a score dialog? I think the usual button is »OK«,
>   which is also nonsense, but at least common nonsense.
> 
Yes, you're absolutely right. "OK" would make more sense. 

>>At the moment, I have a single class that gets invoked to show both
>>the interim score and the final score.
> 
>   Classes can not be invoked. Methods can be invoked. What you
>   mean is »a class, an instance of which is created to show ...«.
> 
>>While the dialog is simple and works just fine, I suspect I'm
>>violating some OO principles by making the behavior of the
>>class change depending on what kind of score is being shown. 
> 
>   I am not aware, whether such a principle exist, but you
>   could also use:
> 
> class InterimScore extends Score { public InterimScore(){ super( true 
> ); }} class FinalScore   extends Score { public FinalScore(){   super(
> false ); }} 
> 

Yes, I can see the advantage of that.

>>Or is there a better way?
> 
>   If your boolean approach is working fine, I see no need to
>   change it. What you think of are the template method or
>   strategy patterns, but there is no need to apply them here.
> 
Thanks for explaining your reasoning to me, Stefan.





-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10873

On Mon, 19 Dec 2011 00:13:07 +0000 (UTC), Novice <novice@example..com>
wrote, quoted or indirectly quoted someone who said :

>At the moment, I have a single class that gets invoked to show both the 
>interim score and the final score. 

That seems completely reasonable.  In fact is it rather light duty for
a single class.  I would have expected a method for at least
incrementing the score.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.
 

[toc] | [prev] | [next] | [standalone]

#10882

On Mon, 19 Dec 2011 00:13:07 +0000 (UTC), Novice <novice@example..com>
wrote:

[snip]

>Or is there a better way?  

     KISS (Keep It Simple, Stupid).

     Why bother with classes?  What do they give you?  Is it very
much?  It is important to answer this.

     When I was taking my degree, I had a course on operating systems.
One assignment was to compare the performance of various algorithms
for CPU allocation.  One of my classmates tried the OOP approach.  He
ended up having to scrap his program and start over.  He did not
complete the assignment.  My approach was to write procedural code.  I
saw no need for classes and so did not use them.  My program worked
fine.  The instructor was impressed with the layout of the output.

     OOP is fine, but you appear to be trying to use it for the sake
of using it.  OOP is a tool.  Use a correct tool correctly.

     So again, what does using classes buy you?  Or do they just
gratuitously complicate your program?

     There are a number of acceptable answers.  If you are just
learning OOP, using it could be a good exercise in using a simple
example so you can be sure you understand.  This does not mean that it
is, in general, a good approach for your problem.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#10902

On Monday, December 19, 2011 11:38:09 AM UTC-8, Gene Wirchenko wrote:
> On Mon, 19 Dec 2011 00:13:07 +0000 (UTC), Novice <novice@example..com>
> wrote:
> 
> [snip]
> 
> >Or is there a better way?  
> 
>      KISS (Keep It Simple, Stupid).
> 
>      Why bother with classes?  What do they give you?  Is it very
> much?  It is important to answer this.
> 
>      When I was taking my degree, I had a course on operating systems.
> One assignment was to compare the performance of various algorithms
> for CPU allocation.  One of my classmates tried the OOP approach.  He
> ended up having to scrap his program and start over.  He did not
> complete the assignment.  My approach was to write procedural code.  I
> saw no need for classes and so did not use them.  My program worked
> fine.  The instructor was impressed with the layout of the output.

So you are a better programmer.  Doesn't mean that procedural is better than OOP.

>      OOP is fine, but you appear to be trying to use it for the sake
> of using it.  OOP is a tool.  Use a correct tool correctly.

+1

But understand that "OOP" is just a buzzword for "good design".  If you follow good design practices, some people might accuse you of using object orientation.

>      So again, what does using classes buy you?  Or do they just
> gratuitously complicate your program?

"Using classes" != "object-oriented programming"

The answer is that they buy you a lot, and do not gratuitously complicate your programming, unless you design them to do so.

Any good introductory text on object-oriented programming will explain the benefits better than a Usenet post can.

>      There are a number of acceptable answers.  If you are just
> learning OOP, using it could be a good exercise in using a simple
> example so you can be sure you understand.  This does not mean that it
> is, in general, a good approach for your problem.

And yet it is.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10910

On Tue, 20 Dec 2011 07:42:10 -0800 (PST), Lew <lewbloch@gmail.com>
wrote:

>On Monday, December 19, 2011 11:38:09 AM UTC-8, Gene Wirchenko wrote:
>> On Mon, 19 Dec 2011 00:13:07 +0000 (UTC), Novice <novice@example..com>
>> wrote:
>> 
>> [snip]
>> 
>> >Or is there a better way?  
>> 
>>      KISS (Keep It Simple, Stupid).
>> 
>>      Why bother with classes?  What do they give you?  Is it very
>> much?  It is important to answer this.
>> 
>>      When I was taking my degree, I had a course on operating systems.
>> One assignment was to compare the performance of various algorithms
>> for CPU allocation.  One of my classmates tried the OOP approach.  He
>> ended up having to scrap his program and start over.  He did not
>> complete the assignment.  My approach was to write procedural code.  I
>> saw no need for classes and so did not use them.  My program worked
>> fine.  The instructor was impressed with the layout of the output.
>
>So you are a better programmer.  Doesn't mean that procedural is better than OOP.

     Straw man argument.  My classmate got into a bunch of complexity
that he did not need to.

     In general, I go for simpler code.  Sometimes, that is OOP, and
sometimes, that is procedural.

>>      OOP is fine, but you appear to be trying to use it for the sake
>> of using it.  OOP is a tool.  Use a correct tool correctly.
>
>+1

     And note that I wrote "a", not "the".  There are too many
arguments about what is best when, often, a number of ways will work
just fine.

>But understand that "OOP" is just a buzzword for "good design".  If you follow
 good design practices, some people might accuse you of using object
orientation.

     OOP is a bit more than that.

>>      So again, what does using classes buy you?  Or do they just
>> gratuitously complicate your program?
>
>"Using classes" != "object-oriented programming"

     OP was asking about whether he should use more than one class.

>The answer is that they buy you a lot, and do not gratuitously complicate
 your programming, unless you design them to do so.

     They can buy you a lot, and they can gratuitously complicate a
program.  The devil is in the details^Wimplementation.

>Any good introductory text on object-oriented programming will explain the benefits better than a Usenet post can.

     Sure.

>>      There are a number of acceptable answers.  If you are just
>> learning OOP, using it could be a good exercise in using a simple
>> example so you can be sure you understand.  This does not mean that it
>> is, in general, a good approach for your problem.
>
>And yet it is.

     Nope.  It is a tool.  There are areas where it is good, and
others where it is not.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web