软件设计模式——基于java平台和运用5种设计模式的五子棋游戏
二、设计要求
仿照教材上面围棋软件的设计思路，设计一款五子棋，采用至少5种设计模式。
三、引言
五子棋相传起源于四千多年前的尧帝时期，比围棋的历史还要悠久，可能早在“尧造围棋”之前，民间就已有五子棋游戏。有关早期五子棋的文史资料与围棋有相似之处，因为古代五子棋的棋具与围棋是完全相同的。在上古的神话传说中有“女娲造人，伏羲做棋”一说，《增山海经》中记载：“休舆之山有石焉，名曰帝台之棋，五色而文状鹑卵。”李善注引三国魏邯郸淳《艺经》中曰：“棋局，纵横各十七道，合二百八十九道，白黑棋子，各一百五十枚”。可见，五子棋颇有渊源。亦有传说，五子棋最初流行于少数民族地区，以后渐渐演变成围棋并在炎黄子孙后代中遍及开来。
五子棋是全国智力运动会竞技项目之一，是一种两人对弈的纯策略型棋类游戏。五子棋的棋具与围棋通用，是一种传统的棋种，有两种玩法。一种是双方分别使用黑白两色的棋子，下在棋盘直线与横线的交叉点上，先形成五子连线者获胜。还有一种是自己形成五子连线就替换对方任意一枚棋子。被替换的棋子可以和对方交换棋子。最后以先出完所有棋子的一方为胜。
五子棋容易上手，老少皆宜，而且趣味横生，引人入胜；它不仅能增强思维能力，提高智力，而且富含哲理，有助于修身养性。
四、设计模式1.1 抽象工厂模式
1.1.1 所用模式结构视图
1.1.2 本实例类图
1.1.3 实例实现代码
Theme类代码:
ThemeA类代码：
BackImage类代码：
BackImageA类代码：
Button类代码：
ButtonA类代码：
1.1.4 当前模式总结
抽象工厂模式是指提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。本项目利用抽象工厂模式定义三种不同的游戏背景，供用户切换。
抽象工厂模式优点：
（1）：最大的好处便是易于交换产品系列，由于具体工厂类，在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同产品配置。
（2）：它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操作实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。
抽象工厂模式缺点
（1）：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。
1.2 备忘录模式
1.2.1 所用模式结构视图
1.2.2 本实例类图
1.2.3 实例实现代码
ChessPosition类代码：
Memento类代码：
Caretaker类代码：
1.2.4 当前模式总结
备忘录模式是在不破坏封闭的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。本项目使用备忘录模式，允许用户悔棋。
备忘录模式优点：
（1）：给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。
（2）：实现了信息的封装，使得用户不需要关心状态的保存细节。
备忘录模式缺点
（1）：消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
1.3 责任链模式
1.3.1 所用模式结构视图
1.3.2 本实例类图
1.3.3 实例实现代码
Officer类代码：
PersonAlgorithm类代码：
SystemAlgorithm类代码：
1.3.4 当前模式总结
责任链模式给予请求的类型，对请求的发送者和接收者进行解耦。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。使用责任链模式来决定是人类悔棋还是人机。
责任链模式的优点
（1）降低耦合度。它将请求的发送者和接收者解耦。
（2）简化了对象。使得对象不需要知道链的结构。
（3）增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。
（4）增加新的请求处理类很方便。
责任链模式的缺点
（1）不能保证请求一定被接收。
（2）系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。
（3）可能不容易观察运行时的特征，有碍于除错。
1.4 单例模式
1.4.1 所用模式结构视图
1.4.2 本实例类图
1.4.3 实例实现代码
Chess接口代码：
BlackChess类代码：
WhiteChess类代码：
1.4.4 当前模式总结
单例模式是指确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。避免在同一位置产生多个棋子，同时避免一个棋子实例被唯一创建，采用单例模式中的饿汉模式。
单例模式的优点：
（1）单例模式可以保证内存里只有一个实例，减少了内存的开销；可以避免对资源的多重占用，单例模式设置全局访问点；可以优化和共享资源的访问。
单例模式的缺点：
（1）单例模式一般没有接口，扩展困难。如果要扩展，则除了修改原来的代码，没有第二种途径，违背开闭原则；在并发测试中，单例模式不利于代码调试。在调试过程中，如果单例中的代码没有执行完，也不能模拟生成一个新的对象；单例模式的功能代码通常写在一个类中。
1.5 享元模式
1.5.1 所用模式结构视图
1.5.2 本实例类图
1.5.3 实例实现代码
ChessBox类代码：
Chess接口代码：
BlackChess类代码：
WhiteChess类代码：
ChessPosition类代码：
1.5.4 当前模式总结
享元模式运用共享技术有效的支持大量细粒度对象的复用，系统只适用少量的对象而这些对象都很相似，状态变化很小可以实现对象的多次复用。享元模式使得棋盘中存在大量的棋子而无需创建许多的棋子实例。
享元模式的优点
（1）大大减少了对象的创建，降低了程序内存的占用，提高效率。
享元模式的缺点
（2）提高了系统的复杂度。需要区分内蕴状态(享元内部，不会随着环境的改变而有所不同)和外蕴状态（随着环境的改变而改变，不可共享）。
五、系统实现
1.1包图
1.2分析类图
1.3界面展示
进入游戏界面：
开始游戏界面：
选择游戏模式界面：
选择棋盘主题界面：
普通棋盘主题界面：
中级棋盘主题界面：
高级棋盘主题界面：
悔棋请求界面：
拒绝悔棋界面：
认输界面：
胜利界面：
