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