java – OO对于用户交互的简单

发布时间：2020-12-14 05:33:18 所属栏目：Java 来源：网络整理

导读：作为一个夏天的项目,当我有一些Uni的停机时间,我将要建立一个垄断游戏.这个问题更多的是关于这个问题的总体思路,而不是我要执行的具体任务. 我决定用自下而上的方法来建造这个,创造四十个太空板周围的运动,然后继续与空间交互.我意识到我不确定最好的方法来

作为一个夏天的项目,当我有一些Uni的停机时间,我将要建立一个垄断游戏.这个问题更多的是关于这个问题的总体思路,而不是我要执行的具体任务.

我决定用自下而上的方法来建造这个,创造四十个太空板周围的运动,然后继续与空间交互.我意识到我不确定最好的方法来处理这个问题,而且我在两个设计思路之间撕裂了：

>给每个空间自己的对象,一个Space对象的所有子类,以便交互可以由空间对象本身定义.我可以通过为每种类型的空间实现不同的land()方法来实现.
>只给属性和实用程序(每个属性都有独特的功能)对象和创建方法来处理程序的主要类(或者我正在调用的主板)中的购买/租赁等.空间如超级税可以通过一小组条件检查来查看玩家是否在特殊空间上.

选项1显然是OO(而且我觉得正确的)做事的方式,但是我只想处理来自程序主类的用户交互.换句话说,我不希望空间物体与播放器进行交互.
为什么？ Errr.到目前为止,我已经做了很多编码,这样做很简单,但是我不知道这对于大型项目是否是管道梦想.我应该真的在一个完全独立的类中处理用户交互吗？

正如你所看到的,我对这种情况感到很困惑.有没有办法呢？而且,有没有人有任何关于实用OO设计的建议,可以帮助一般？

编辑：就像注意到,我觉得我在这个问题上失去了一点关注.我对真正组合OO和任何外部动作(命令行,网络,GUI,文件管理等)的一般方法感兴趣.

解决方法

最后,由你决定.那就是OO的美丽,因为它是被解释的.通常应遵循一些模式,但一般来说,您的决定如何处理.

但是,您应该仔细考虑系统中的每位演员应该了解其余部分.物业真的知道玩家,账户余额和其他玩家吗？可能不会.财产应该知道它的费用,租金是多少等等

另一方面,主要的线索是否应该关心租金等琐事呢？可能不会.它的主要关注应该是游戏本身的状态,如骰子滚动,每个玩家是否要交易或购买或不正当抵押,这样的事情.

想想一下关于登上广场的行动.一旦登陆,玩家有3个选择：

>购买房产
>忽略该属性
>支付租金

现在,系统中的哪个角色知道完成这一点所需的所有信息.我们有Game类,不关心这样的麻烦.我们拥有物业,这并不关心球员.但是Player对象知道所有这些信息.它保存了每个玩家拥有的记录,并且可以轻松访问正确的数据.

所以,如果是我,我会做一个Player.performMove(Die d)方法.它可以轻松访问帐户.这也允许类之间的最小耦合.

但最终,这取决于你.我相信人们已经在完美的OO以及功能或程序语言中创建了垄断克隆.最后,使用您所知道的并保持重构,直到您对最终设计满意为止.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!