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