解决实际中的大问题solving
really big problems
| 引言 |
时候构建一些真实的大东西了。你准备好了吗？are you ready？你已经掌握了一系列的OOA&D工具，但是在现实环境中构造一个大系统的时候，如何使用它们呢?好吧，你可能还没有认识到，但是你已经具备了构造大系统的一切条件。接下来，你将会学习一些新的工具，例如：领域分析和用例图，但是这些新工具是你以前学习的知识作为基础的，例如:倾听客户的需求，并且在开始写代码之前，理解你要构建的系统是什么。准备好，是时候开始架构师工作了。
| 正文 |
所有的材料显示开发一个伟大的软件非常棒，但是真实的应用可不只是5个或者是10个类。
解决大问题和解决小问题是相同的。
在前面我们做的那个小应用，Guitar商店小于15个类，狗门小于5个类。但是，到目前为止，你所学的一切都可以运用到开发大系统中。
记得开发伟大的软件的三个步骤吗？
1、确保你的软件做了用户需要的事情。
2、应用基本的OO原则来增加灵活性。
3、为可维护、可重用的设计而奋斗。
一切在于你如何看待大问题。
在你解决大问题的时候，也只能是从其中一个部分开始工作。
看待大问题最好的方式，就是将它分解为很多独立的小功能。可以独立的解决这些小功能，并且在它上面应用你学到的知识。
你已经知道的一些知识
在前面你已经学到了很多的知识，都可以用来帮助你解决大问题，只是你可能还没有意识到。下面列出一些已经学到的知识。
- 通过封装变化，是的你的应用更加灵活，更加容易适应变化。
- 针对接口编程，而不是针对实现编程，是你的软件更容易扩展。
- 获取需求的最好办法是系统需要实现什么。
- 分析帮助你确保你的系统可以工作在一个真实的环境。
- 伟大的软件应该是容易修改和扩展的，是做了用户想要做的事情。
下面就让我们来解决大问题吧。先看一个问题的描述。
|
Gary Games ——场景描述 |
| 游戏提供一个框架，通过框架，游戏设计者可以创建一个回合战略型游戏。没有凶杀的场景，游戏利用听觉和视觉吸引玩游戏的人，我们的游戏突出战略和战术的技术细节。 |
requirements和use case是一个不错的开始，通过这些你可以想象出系统的样子，让后一点一点的增加功能，通过解决一个一个的小问题，然后来解决大问题。
但是我们知道的内容足够进行下面的工作了吗？好像不太够，Gary到底是一个什么样子的平台呢？谁是最终的消费者呢？是游戏者还是游戏设计者？游戏都是历史背景题材的吗？是否需要支持激光和空间飞船呢？如果要写一个好的需求，我们还需要知道更多的内容。
我们需要先弄清楚两个事情。
- 系统像什么？
- 系统不像什么？
我们还需要倾听一下客户关于这个游戏更加细节的讨论。
通过用户的需求描述，可以得出功能列表。
什么是一个功能呢？一个功能就是对于系统需要做的一件事的高级别的描述。通常你通过和客户聊天，或者是倾听客户的描述来获取功能。
通过用户描述的功能，转化为需求的描述。还记得我前面说的吗，用户很多时候也不清楚他们的需求什么，或者说他们说不清楚需求是什么。需要我们去挖掘，但是用户会说他需要一个功能。根据这个功能我们把它变成需求描述，然后和客户一起确认需求。
需求也有两种，一种是给用户的，作为甲乙双方的确认文件。一种是给内部用的，主要给开发人员，用来控制开发边界的，同时对开发人员有一个方向性的指导作用，不至于蔓延的没有边界了或者是没有开发的的方向。通常第二种需求是由架构设计人员整理的。
例如：客户说想在游戏中支持不同的地形。
我们就会分析
- 一个文件关联一个地形
- 游戏设计者可以创建自定义的地形
- 每个地形的特征，会影响在上面的单位的移动
也就是一个功能会导致多个需求。
我们已经拿到了功能描述，是不是就可以开始写use case了呢？
不是的，用例不会帮助你从大局上看系统。当你进行真实开发的时候，尽量推迟细节的实现。你仍然需要知道系统需要做什么，从全局上，系统需要做什么？
这时候我们需要用例图来辅助确定系统需要做什么，而不是对于细节的use case描述。
上面就是一张用例图，也就是系统的一个蓝图。
| 结论 |
解决大问题
1、倾听客户的描述，并且想象出他们想要你构建的系统是什么样子的。
2、以一种用户可以理解的语言列出一个功能单。
3、确保你的功能是用户想要的。
4、使用use case图来展示系统的蓝图
5、将大系统分解为许多的小部分
6、在这些小部分上应用设计模式
7、在这些小部分上应用基本的OOA&D原则
OO原则
1、封装变化
2、针对接口编程，而不针对实现编程
3、每个类应该只有一个导致它变化的原因
4、类是功能和行为的集合