第三部分细化迭代1--基础17-18章.ppt

游戏循环算法 轮次（turn） 游戏者投掷骰子并且移动棋子。 回合（round） 所有游戏者完成一个轮次。 For N rounds for each Player p p takes a turn 谁来负责游戏循环？ 非控制器，非创建，信息专家模式？ 所需信息 谁持有这些信息 当前回合数 目前还没有相应的对象，但是为了实现低表示差异，将该职责分配给MonopolyGame是合理的。 所有游戏者（这样才能使每个游戏者完成其轮次） 籍由领域模型，MonopolyGame是合适的候选者 使用了私有的内部的playRound方法： 优秀的OO方法设计提倡使用具有单一目标的小型方法，这样可以在该方法级别上支持高内聚； playRound名字来源于领域词汇，增加理解 谁来完成每一轮次的活动？ 每个轮次都包括掷骰子，并且根据骰子的总点数将棋子移动到相应的方格里。 专家模式：现实中由游戏者完成其轮次的活动，所以将该职责分配给Player? 违反高内聚和低耦合原则，使对象过于庞大。 就如Pos领域中，Cashier软件对象要完成几乎所有的操作! 对象设计要根据信息专家（和其他）原则将职责分配给众多对象！ 所需信息 谁持有这些信息 游戏者当前的位置（知道移动的起点） 根据领域模型，Piece知道其所在的Square，Player知道代表它的Piece。所以根据LRG，Player软件对象能够知道其当前位置。 两个Die对象（用以抛掷并计算总点数） 根据领域模型，既然我们认定骰子是游戏的一部分，那么MonopolyGame可以作为候选者 所有方格——方格的组织（以便移动到正确的方格） 基于LRG，Board是合理的候选者 完成该职责需要什么信息？ 准则： 当有多个局部信息专家有待选择时，将职责赋予具有支配作用的信息专家，即持有主要信息的对象。这样有助于支持低耦合。 本案例所有候选者持有1/3的信息，信息量相等 当存在多个设计选择时，考虑每个选择对耦合和内聚的影响，由此选择最佳的方案。 MOnopolyGame已经承担了一些工作，但是Player和Board都没有 当基于其他准则还无法明确选择出适当的方案时，则要考虑这些软件对象在未来可能的演化以及信息专家、内聚和耦合等方面的影响。 出现了三个局部信息专家，怎么解决？ 应用第三准则： 哪个对象会知道游戏者的现金总量：Player 哪个对象会知道游戏者的色彩方案？Player 完成一个轮次 完成一个轮次意味着： 计算2~12之间的随机数（两个骰子点数总和的范围） 根据信息专家模式，Die应该能够“抛掷”其自身，并负责计算其属性faceValue 计算下一个方格的位置 根据信息专家模式，Board将负责根据原来的方格位置和偏移量（骰子的总点数）来计算新的方格位置。 将游戏者的棋子从原来的位置移动到新的方格里。 根据信息专家模式，Piece将设置其新的位置，但是该位置可能是接收自其属主，即Player。 谁来协调所有的工作？ 上面三个步骤须由某个对象协调。 Player负责完成轮次活动，所以由Player来进行协调。 可见性的问题: Player来协调这些步骤意味着它要与Die、Board和Piece对象进行协作，也就暗示了可见性需求。 通常可以在启动过程中初始化Player，使其具有对这些对象的永久性引用。 最终设计 命令—查询分离原则（CQS） 风格1：在正式解决方案中使用 public void roll() { faceValue = // random num generation } public int getFaceValue() { return faceValue; } 风格2：将两个方法合并 public int roll() { faceValue = // random num generation return faceValue; } 命令—查询分离原则 能否合二为一？ 不能，违反了命令－查询原则。 命令－查询（Command-Quary Separation Principle）原则 任何方法都可能是如下一种情况之一： 执行动作（更新，调整，……）的命令方法，这种方法通常有改变对象状态等副作用，并且是void的。 向调用者返回数据的查询，这种方法没有副作用，不会永久性地改变对象的状态。 关键是，一个方法不应该同时属于以上两种类型。 动机：为何有所困扰？ 违反命令－查询分离原则，可能产生令人不快的意外，违反软件开发中最小意外的原则。 Missle m = new Missle(); String name = m.getName(); … public