Head.First.Object-Oriented.Design.and.Analysis《深入浅出面向对象的分析与设计》读书笔记（七）

 

解决实际中的大问题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、类是功能和行为的集合