Java Reference
In-Depth Information
weight), we realize that this is information about a player ! The logical thing to do (following
responsibility-driven design guidelines) is to create a Player class. We can then add these
fields to the Player class and create a Player object at the start of the game, to store the data.
The existing field currentRoom also stores information about the player: the player's current
location. Consequently, we should now also move this field into the Player class.
Analyzing it now, it is obvious that this design better fits the principle of responsibility-driven
design. Who should be responsible for storing information about the player? The Player class,
of course.
In the original version, we had only a single piece of information for the player: the current room.
Whether we should have had a Player class even back then is up for discussion. There are argu-
ments both ways. It would have been nice design, so, yes, maybe we should. But having a class with
only a single field and no methods that do anything of significance might be regarded as overkill.
Sometimes there are gray areas such as this one, where either decision is defensible. But after
adding our new fields, the situation is quite clear. There is now a strong argument for a Player
class. It would store the fields and have methods such as dropItem and pickUpItem (which
can include the weight check and might return false if we cannot carry it).
What we did when we introduced the Player class and moved the currentRoom field from
Game into Player was refactoring. We have restructured the way we represent our data, to
achieve a better design under changed requirements.
Programmers not as well trained as us (or just being lazy) might have left the currentRoom
field where it was, seeing that the program worked as it was and there did not seem to be a great
need to make this change. They would end up with a messy class design.
The effect of making the change can be seen if we think one step further ahead. Assume that
we now want to extend the game to allow for multiple players. With our nice new design, this
is suddenly very easy. We already have a Player class (the Game holds a Player object), and
it is easy to create several Player objects and store in Game a collection of players instead
of a single player. Each player object would hold its own current room, items, and maximum
weight. Different players could even have different maximum weights, opening up the even
wider concept of having players with quite different capabilities—their carrying capability be-
ing just one of possibly many.
The lazy programmer who left currentRoom in the Game class, however, has a serious problem
now. Because the whole game has only a single current room, current locations of multiple players
cannot easily be stored. Bad design usually bites back later to create more work for us in the end.
Doing good refactoring is as much about thinking in a certain mindset as it is about technical
skills. While we make changes and extensions to applications, we should regularly question
whether an original class design still represents the best solution. As the functionality changes,
arguments for or against certain designs change. What was a good design for a simple applica-
tion might not be good any more when some extensions are added.
Recognizing these changes and actually making the refactoring modifications to the source
code usually saves a lot of time and effort in the end. The earlier we clean up our design, the
more work we usually save.
Search WWH ::




Custom Search