修正一些翻译错误

Author: tkchu

book/command.markdown

@@ -11,7 +11,7 @@
 
 我想你也会觉得这个句子晦涩难懂。
 第一，它的比喻难以理解。
-在软件之外的狂野世界，词语可以指代任何事物，“客户”是一个*人*——那些和你做生意的人。
+在词语可以指代任何事物的狂野软件世界之外，“客户”是一个*人*——那些和你做生意的人。
 据我查证，人类不能被“参数化”。
 
 然后，句子余下的部分介绍了可能会使用这个模式的场景。
@@ -122,15 +122,15 @@
 ## 角色说明
 
 我们刚才定义的类可以在之前的例子上正常工作，但有很大的局限。
-问题在于假设顶层的`jump()`, `fireGun()`之类的函数可以找到玩家的角色，然后像操纵木偶一样操纵它。
+问题在于假设了顶层的`jump()`, `fireGun()`之类的函数可以找到玩家角色，然后像木偶一样操纵它。
 
 这些假定的耦合限制了这些命令的用处。`JumpCommand`*只能* 让玩家的角色跳跃。让我们放松这个限制。
 不让函数去找它们控制的角色，我们将函数控制的角色对象*传进去*：
 
 ^code actor-command
 
 这里的`GameActor`是代表游戏世界中角色的“游戏对象”类。
-我们将其传给`execute()`，这样可以在命令的子类中添加函数，来与我们选择的角色关联，就像这样：
+我们将其传给`execute()`，这样命令类的子类就可以调用所选游戏对象上的方法，就像这样：
 
 ^code jump-actor
 
@@ -158,9 +158,9 @@
 
 在选择命令的AI和展现命令的游戏角色间解耦给了我们很大的灵活度。
 我们可以对不同的角色使用不同的AI，或者为了不同的行为而混合AI。
-想要一个更加有攻击性的同伴？插入一个更加有攻击性的AI为其生成命令。
+想要一个更加有攻击性的对手？插入一个更加有攻击性的AI为其生成命令。
 事实上，我们甚至可以为*玩家角色*加上AI，
-在原型阶段游戏需要自动演示时，这是很有用的。
+在展示阶段，游戏需要自动演示时，这是很有用的。
 
 <span name="queue"></span>把控制角色的命令变为第一公民对象，去除直接方法调用中严厉的束缚。
 将其视为命令队列，或者是命令流：
@@ -198,7 +198,7 @@
 最后的这个例子是这种模式最广为人知的使用情况。
 如果一个命令对象可以*做*一件事，那么它亦可以*撤销*这件事。
 在一些策略游戏中使用撤销，这样你就可以回滚那些你不喜欢的操作。
-在人们*创造*游戏时，这是*必不可少的*工具。
+它是*创造*游戏时*必不可少的*工具。
 一个不能撤销误操作导致的错误的编辑器，肯定会让游戏设计师恨你。
 
 <aside name="hate">
@@ -253,7 +253,7 @@
 
 这看上去是<a href="http://en.wikipedia.org/wiki/Memento_pattern"
 class="gof-pattern">备忘录</a>模式使用的地方，它从来没有有效地工作过。
-由于命令趋向于修改对象状态的一小部分，对数据其他部分的快照就是浪费内存。手动存储改动的部分消耗更小。
+由于命令趋向于修改对象状态的一小部分，对数据其他部分的快照就是浪费内存。手动内存管理的消耗更小。
 
 *<a href="http://en.wikipedia.org/wiki/Persistent_data_structure">持久化数据结构</a>*是另一个选项。
 使用它，每次修改对象都返回一个新对象，保持原来的对象不变。巧妙的实现下，这些新对象与之前的对象共享数据，所以比克隆整个对象开销更小。