上周就获悉我和一位学弟做的东软杯的比赛项目已经晋级决赛，于这周二晚上进行决赛。由于我要考试，所以没办法去给学弟助阵，只是对软件的结构写点介绍性的文字，帮助他到时候上台讲解。
其实这个东西有多么烂的表现层我们心理都很清楚，但为什么能进决赛？说明——别人的比我们更烂！！哈哈～废话不多说了，不管有多烂，毕竟自己曾经花时间做过的东西，就留作纪念吧，要说维护的话其实也难——我没多少时间再去帮他维护了...这里把我为他明天写的东西贴上来留作纪念吧，我很少写那么多字，我也讨厌写那么多文字，不容易，所以一定要贴出来留个纪念：
软件结构示意图：
1） 软件结构简介：本软件采用分层结构设计，自顶向下分为表现层、逻辑层、服务层和数据层。数据层负责组织软件中用到的数据，采用 xml 文件格式存储；服务层提供了对底层数据的存取的基本功能，是上面一层（逻辑层）获得数据的唯一通道，仿 DAO 模式构建；再上面一层的逻辑层是整个软件功能实现的基础，它提供了一系列与软件主要功能相关的类来实现主要功能，如生成试题、播放音乐、为试题打分等，上面的表现层将调用逻辑层的类来构成界面；最上面一层就是表现层了，采用 Java Swing GUI 做成的用户界面。
2） 可拆卸的表现层：其中，表现层需要调用逻辑层里定义的各种功能，但它并不是简单地直接调用。这里运用了 Façade[fesa:d] 设计模式将逻辑层中各类的与主要功能相关的方法汇总、组织了起来，所以整个表现层和整个逻辑层都只通过这个仅有的 Façade 模式实现类联系了起来，实现了松散耦合。界面的大规模改动并不会影响到逻辑功能的实现，这方便了今后对界面的改进。不仅如此，这个 Façade 模式的实现类还为我们的软件带来另一种可能的便利：更换表现层。也就是说，如果我们今后打算做一个 B/S 架构的类似软件的话，只需要把 Swing 的表现层拆掉，换上基于 JSP 技术的表现层即可，这种方便可拆卸的表现层设计能增加软件各部分重用的可能。
3） 面向接口的设计：各层之间的耦合基本上全部通过接口，也就是说上面一层对下面一层的“了解”只是接口而已，方便下面一层对上面一层隐藏具体实现。例如，数据层中 DataLoader 接口的实现类是用来操作底层数据的，但上面一层（服务层）只通过 DataLoader 接口和数据层耦合， DataLoader 的具体实现完全不知晓。也就是说若今后打算改用数据库来存储软件的数据的话，只需要再编写一个支持数据库操作的 DataLoader 实现类，再通过修改配置文件将其依赖注入到服务层即可，而服务层本身的代码不需要任何改动，和先前使用 xml 存储时的行为完全一样。这方便了数据的移植，进一步增加了可重用性。若再要切换回 xml 文件存储方式的话也只需要改改配置文件。
4） Xml 文件存储数据：选用 xml 文件对数据进行存储是因为 xml 文件本身是纯文本文件，占用空间不算大，但比一般的纯文本文件优越的地方是 xml 文件能方便地描述数据的存储结构，其描述数据存储结构的能力更接近数据库，使得软件能够直接从中读取有一定组织结构的数据。比如阅读题的数据分为题目名、文章、五个问题以及每个问题的四个选项，软件利用 Java 标准库中的 xml 操作相关的 API 能够直接而准确地得到任何一道阅读题的完整数据，并封装成相应的传值对象交给逻辑层处理，非常方便。若采用二进制文件存数据的话，虽然节省空间一点，但会增加设计存储结构的工作量，增加存取操作的代码量，也给今后的维护工作增加了难度。利用 xml 的这些优势，到目前为止，本软件已经毫不费力地收录了四级词库、六级词库、研究生词库共计 8000 多个单词；高质量交响乐及 alpha 波乐 16 首； 3D 图片、静态图片等 60 张；四六级短文十余篇。而在今后的扩展过程中将远远不止这些。
5） 引入 Spring 框架：由于面向接口的设计与工厂模式的结合能产生出各层之间低耦合度的优秀架构，而 Spring 框架正是一个强大的工厂模式实现，用它来管理我们的服务层、数据层的类，并且利用它提供的依赖注入功能为各层类中的接口注入了具体实现类，也就是说代码中没有具体实现类的影子，完全实现了面向接口编程的目标。这样做有利于今后的扩展及代码的重构，使大部分的维护工作只通过增加实现类和修改配置文件即可完成，不需要对既有的类进行更改。
