- 论坛徽章:
- 0
|
这是整个作业的内容，前面的所有问题我都解决了，最后的问题（task 6），有点困惑，因为实在不知道如何做才能让game.java中game.processCommand中不出现“go”，“help”之类的字符串（因为这些字符串和CommandWords.java中的重复，就是说，game类和commandwords类有隐性的联系，如果加入新命令，需要在game类和commandwords类中都加入这个命令）
Basic tasks
This part of the assignment involves material up to chapter 7. We want to extend the functionality of zuul so that:
* Rooms can store any number of items the player might find useful, like books and keys.
* The player can pick up and drop any number of items.
As discussed in the book, you should make an item class and get rooms to store collections of items.
* Task 1: Allow rooms to contain an arbitrary number of items [weight: 1]. An item has a description (a String) and a name (a 1-word String). Issue: what happens if we create two items with the same name? This is not a problem now but it could be later...(Note: the weight following each task refers to roughly how much it is worth.)
The next extension to the functionality is to add a collection for the player to store a variable number of items. The only sensible class in which to store this collection is the Game class, which already records which room the player is currently in. As discussed in the book, however, it is better to refactor zuul to add a Player class which contains all the information about the player. This keeps Game smaller and more cohesive, and would make it easier to implement multi-player games if we wanted to do that.
The first step in refactoring should be to modify the design without modifying the functionality.
* Task 2: Refactor your project to add a Player class and move the currentRoom field from Game to Player [weight: 0].
* Task 3: Extend the Player class so that the player can carry any number of items. Add two commands: "take X" and "drop X" where X is an item. [weight: 2]
Now you have to decide how to handle a situation where two objects have the same name. You can either disallow the situation, or pick up and drop all objects with the same name at the same time, or just pick up or drop the first in the data structure storing them. It doesn't really matter which you choose, but you should document your choice in the source code and test that it is implemented correctly.
More advanced tasks
To make the game more interesting we want to set up a scenario where the player wants to get into a locked room. The key to the room is held by a dwarf (a Non-Player Character, or NPC) and the player has to trade some gold for the key. Once you have implemented the necessary classes you should add the appropriate objects to the world and try things out.
Most of the marks for these tasks will depend on your design choices so think carefully about what classes you should have and how they relate to each other. In the process you will get further experience with refactoring and some advanced object oriented features. These tasks draw on material from chapters 8, 9 and 10.
* Task 4: Add Non-Player Characters (NPCs) to the game. An NPC is like an item in that it has a name and a description. However, unlike items the player cannot pick up or drop an NPC. An NPC is like the player in that it can hold an item but is different in that it can hold only one item at a time and doesn't take actions. We might want to extend the game in future to remove these restrictions but even so there will be differences: an NPC won't have commands to ask for help, or to quit the game for example. Add a "trade X" command (where X is an item the player is carrying), which will cause an NPC to trade its item for the item given to it. Note that this implies that there can be only 1 NPC in each room, but to keep things simple you do not need to check or guarantee that this is true. For simplicity, the NPC will accept any item in trade. [weight: 1]
* Task 5: Alter the functionality of the game so that some exits are doors which can be locked. Add "lock X" and "unlock X" commands where X is the name of a door. The second word specifies which door, which means there can be more than one lockable door in a room (e.g. "lock bigDoor" or "unlock smallDoor" or "lock North"). The lock and unlock commands only work if the player is holding a key. For simplicity it is enough if one key works for all doors. You can decide whether a door can be locked from both sides or only one side, and whether unlocking one side unlocks the other side - there is no right answer. [weight: 1]
* Task 6: Refactor Zuul to address the design flaws discussed below. [weight: 2]
Design flaws in Zuul's Command handling
* Unmodular Command handling
CommandWords defines the words the parser recognises but Game.processCommand defines the effect of these words. This is a bad design because the handling of Commands is split between different classes, breaking the principles of modularisation and responsibility-driven design. It also means Game and CommandWords are coupled -- if you change one you need to change the other. In fact there is code duplication between them -- the same word has to appear as a String in both. Refactor Zuul to make command handling more modular.
* Hard-coded polymorphism
Zuul-better produces different behaviours (polymorphism) for different commands by using if statements in Game.processCommand -- the polymorphism is hard-coded into the flow of control. This is very inflexible. For one thing it couples the class with this logic to any other part of the system which deals with commands. But even more fundamentally, the flow of control is the most primitive way of expressing logic. OO programming allows much more powerful, flexible and abstract ways of doing things.
Both of these design flaws can be fixed using OO programming principles. Some hints:
* Think about what an object really is, and how it differs from a struct in C.
* Think about how Java supports polymorphism -- getting different behaviours from related things.
* Think about how you can represent and manipulate processes at a more abstract level than hard-coding them into the flow of control.
In general, try to use the principles of responsibility-driven design, high cohesion, and low coupling. |
|
免费注册
发表于 2008-04-18 03:57
