Design Question

N

Novice

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?
 
A

Arne Vajhøj

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
 
M

markspace

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.
 
S

Stefan Ram

Novice said:
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.
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.
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 ); }}
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.
 
A

Arved Sandstrom

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
 
N

Novice

markspace said:
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!
 
N

Novice

markspace said:
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!
 
N

Novice

(e-mail address removed)-berlin.de (Stefan Ram) wrote in
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.
»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.
Classes can not be invoked. Methods can be invoked. What you
mean is »a class, an instance of which is created to show ...«.


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.
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.
 
N

Novice

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.
 
R

Roedy Green

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.
 
G

Gene Wirchenko

[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
 
M

Martin Gregorie

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.
 
A

Arved Sandstrom

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
 
S

Stefan Ram

Martin Gregorie said:
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.

One also can start with a »monolithic« program that has no
proper modular class structure and then obtain a class
structure according to today's recommendations by a sequence
of refactorings.
IMO the design of the GUI is extremely important and deserves a lot of
care because,

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.
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.

Also, tastes do differ. I prefer an unobtrusive design with
most commands in the program menu and all the program
operable using the keyboard only. It seems today many
designers (and users?) have other preferences.
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.
 
L

Lew

Arved said:
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.
 
A

Arne Vajhøj

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
 
L

Lew

[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.
 
G

Gene Wirchenko

[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.

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.
"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.


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
 
M

Martin Gregorie

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.
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top