【问题标题】:Making the domain-model of tic tac toe制作井字游戏的领域模型
【发布时间】:2011-02-28 22:30:32
【问题描述】:

我正在尝试制作井字游戏的域模型。然后,我将尝试继续完成统一流程的各个步骤,然后用某种语言(C# 或 Java)实现它。

如果我走的是正确的道路,我想得到一些反馈: alt text http://dl.dropbox.com/u/6187267/shooterpics/tictactoedm.jpg

我用两个演员定义了游戏,Player OPlayer X

  1. 我不确定要同时定义TileTile State。也许我应该只定义一个 Tile 并让 3 个可能的状态专门用于它?
  2. 我不确定什么是最好的:让Player OPlayer X 都与Tic Tac Toe 关联,或者让它们从与Tic Tac Toe 关联的Player 继承。按照图片上显示的设计,理论上我们可以有一个带有 2 个玩家 O 的 Tic Tac Toe 概念,这是不正确的。您对此有何看法?

另外,我在图表中遗漏了什么吗?虽然我看不到井字游戏的其他演员,但我应该有其他演员吗?

谢谢

【问题讨论】:

  • 我不认为瓷砖应该有坐标(或者应该有一个板..它有什么用?)..它只有 9 个瓷砖,它们永远不会改变,我只是从 1 开始编号-9,这样检查胜利状态也更容易一些。我也不确定我是否会使用播放器,你可以想一个交替的符号(O或X)放在瓷砖上,当你找到一个获胜条件时,你只需将分数加1到当前符号计数
  • Board 是 Tiles 的容器。井字游戏有棋盘。这并不意味着我会在类图中拥有这些相同的类。
  • sry 不相关的和 necroposting,你用什么软件做这个图?

标签: c# java oop uml


【解决方案1】:

另一种类分解方法是将 Board and Tile 替换为 Game and Move。游戏将包含一系列合法的移动,移动将包含方坐标(或其他一些标识符)以及玩家 O 还是 X。此方案包含更多信息,允许游戏可以重播和备份。

【讨论】:

    【解决方案2】:

    到你的图表:

    1. 由应该是组合关系而不是关联构成 (Tiles 不能单独存在,Board 的状态由 Tiles 的状态定义。)
    2. Player O 和 Player X 是 Player 类的实例,而不是子类 (玩家 0 和玩家 X 与玩家具有相同的结构,它们具有相同的行为,不同之处在于身份和状态 - 图中的名称)

    当您谈论域模型时(在 UP 的上下文中),您应该忘记创建软件系统,并且只包含对井字游戏的域重要的内容。想想任何游戏是如何被描述的——它有它的规则(准备、回合、游戏结束条件……)、玩家(更多游戏的身份、分数、拥有/控制的组件、角色……)和物理组件(板,代币,人物,卡片......)。如果您接受这些元素作为游戏领域模型的一部分并因此成为您的井字游戏的元模型,那么您应该使用元素,它们是这些元素的实例。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2021-12-04
      • 1970-01-01
      • 2015-06-12
      • 1970-01-01
      • 2015-01-08
      相关资源
      最近更新 更多