代码改变世界

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

2010-07-27 07:18  Virus-BeautyCode  阅读(1710)  评论(0编辑  收藏  举报

 

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