阮毅凡 (20302010010)
命令模式的作用是把程序中一些指令打包成一个命令, 并实现命令接口. 这是一种非常好的设计方法, 能够在每个命令执行前后执行若干前置或后置操作, 并且方便地获取各个操作所需的变量等. 但是, 我在这里没有采用命令模式, 或者说实际上采用的是命令模式的一个改版, 写了命令模式的其他功能(包括 ActionListener 等), 但是没有打包命令类.
不写命令类的第一个原因在于, 命令模式的命令类终究是要知道主控类中的很多数据并且需要调用主程序中的很多方法的. 如果写了命令模式, 就需要在主控类中写很多 get, set 之类的函数, 非常复杂. 像是悔棋这种功能, 本身与游戏耦合程度高, 不如直接加在游戏主代码里面(如果要关闭悔棋功能就直接把最大悔棋次数设为0即可). 而像是移动这种命令, 耦合程度更高, 有成功或不成功两种情况, 还会对玩家类和棋盘类进行修改, 不同操作的执行指令也不同, 做成命令模式并提出来就很麻烦.
第二个原因在于, 升级成命令模式对于我的上个程序而言, 成本较高. 主要在于 move 指令, 原本的写法与主控程序耦合性很高, 要把它分离出来非常麻烦. 此外, bonus 功能, 按照原本的写法就还是主程序的观察者, 改用命令模式后既要作为观察者又要作为命令, 很麻烦.
实际上一开始我觉得命令模式好, 是因为命令模式解决了多个模块都需要打印日志的难题. 之前需要对于每个模块都加入作为观察者的日志类, 初始化非常麻烦. 但是命令模式对于打印日志方面, 还是要根据不同的命令打印不同的东西, 实际上还存在耦合性, 仍然要写大量的 if-else 语句.
后来想到, 要解决这个日志问题, 其实也可以不必把需要打印日志的地方都做成单独的命令类, 而是只要在主程序中加入 ActionListener , 并在对应的命令结束的地方接受一个 ActionPerformed(string) 函数即可. 我最终就是这么写的, 没有单独打包命令类, 但是命令模式中的 ActionListener 等功能都存在.
当然现在还是有问题的. 问题仍然在于, 命令结束后执行的函数, 传入的参数是不确定的. 我目前的解决方案是传入包含了命令结束后状态的字符串, 然后再加以处理, 最后让 ActionListener 中的相关函数统一处理即可. 如果以后有其他的操作, 升级实现起来比较困难. 如果用命令模式可能就可以直接获取各个命令内部的数据, 进行处理.