OOAD培训心得

周末参加了公司组织的“面向对象设计与分析基础”的培训，感觉获益良多。
有些比较好的东西摘出来，标记！

【用户需求观】
        这个名称说起来容易，一切从用户出发，用户的需求决定我们的产品，从用户的角度去考虑问题。但是实践时，我总会考虑这个需求如何对应，那个需求如何实现。这样做不是很好，容易考虑的太多，注意力偏离了正轨，用个大家常说的词就是“不上道”。
        需求分析阶段，应该把系统当成一个黑盒，这时，我们需要做的就是规定他与外界交互，让他拥有最基本的完成用户需要的功能。
   
【功能的划分】
        这个问题说多了，可以用整个一篇文章，这里我们只考虑需求阶段，在这个阶段，还是那句话，不要过多的考虑实现。
        在我的第一个项目里，因为是新手，所以我很小心的考虑了很多，比如这个功能可以和哪些功能联系在一起，比如这个功能可能用到的技术。从而造成了这样一个问题，当考虑第一个问题的时候，ok，一切都是空白，然后把他的基本功能列出来，把他可能用到的技术列出来，然后继续，随着发现的需求的增多，我考虑的问题也就随之增多，从而不容易将它们系统的梳理出来，形成的需求式样书就很混乱。
        需求的分类，应该尽量多考虑的是用户提出的最原始的功能，按功能分类，而不是按实现分类。当然并不是不考虑实现，需求整理出来后，在评审过程中，才是考虑这些需求可行性的时候。
        不得不说的是最让人头疼的“隐藏需求”，系统的启动和推出，是最容易忽略的地方，另一个就是默认值这样的隐藏需求。需要向用户确认。特别是设计到界面和多用户的时候更加需要小心谨慎。

【粒度】
        拿“学生选课系统”来说，最基本的需求就是能够选课，对于这个笼统的功能，可以演化出很多更细的功能，比如说选主干课，选辅修课，选主干课备选课等等。这些更细的功能如何被全部发掘出来，隐含的问题如课程的先行条件应该什么时候考虑？这就需要对粒度的把握。
        一般而言，可以分为这么几个层次：

1. 第一个层次只注重用户提出的大功能，把用户提出的最笼统的功能拿出来。如选课。
2. 第二个层次找出实现完整功能的那些具体功能。如选主干课等。
3. 第三个层次找出那些隐藏需求，如某一类课程的先行条件等。
4. 第四个层次是界面，对于一个与用户交互的程序，最重要的可能就是人机界面的友好性和易用性，这时候会经常遇到默认值，状态迁移等问题，需要进行细致的考虑和确认。

        这里赞美一下Rational Rose这个工具，实际操作时，可以先考虑画出“基本用例”（大功能），然后在根据这个基本用力细化为“包含用例”和“扩展用例”（实现大功能的小功能）。这样我们会很自然的进行前两个层次的需求整理，至于后两层次则更多的需要缜密的思路和经验。
        说一句题外话，根据这些包含用例和扩展用例，我们很自然的会想到“模板模式”和“装饰者模式”。

【用例分析】
        Rose提供了分析类这样的概念，又把开发者很自然的拉到了经典的“MVC模式”中。
        Use Case是由Actor触发的，根据这种关系可以把一个用例模型细化为：

1. 负责与用户交互的接口类；
2. 负责业务逻辑的控制类（控制类的设计原则有时候在于非功能性的需求，如性能等，当这些非功能性的需求很少时而且业务逻辑也不复杂时可以省略MVC中的C，就像MS的Document./View模型一样）；
3. 负责与设备交互的实体类。

        而Actor从概念上可以分为三类：人，系统，设备/计时器。所以接口类又可分为三类：
        用户接口类，用户接受外界的输入和向外界展现数据；
        系统接口类，用于内部模块的通信协议；
        设备接口类，负责处理设备的信息。

        再说一句题外话，每个Use Case会对应1…n个事件流。而事件流又可分为基本流和备选流，这就可以用多态去封装变化。
        不得不提到的是检查参数的有效性这样的操作应该让那种类负责？？？谁有决定数据是否有效的权利？当然是负责处理数据的实体类。虽然有时候这可能有点像业务逻辑方面的东西，但是仔细考虑后就会发现，数据的有效性这样的问题可能经常会变化，想要在变化时使他影响的范围最小，那么交给实体类是个不错的注意。控制类的职责是业务流程/工作的分配。

【用例驱动的设计】
        用户的需求才是指导设计的最重要的准则。从分析类出发，就会到设计模型的元素，这些元素最可能的是一系列的类，但要组织这些类，准则是很难把握的，毕竟项目是不可能完全相同的。可能要说原则那就是高内聚、低耦合，这并不是OO所特有的，面向过程同样遵从该原则。
         用例是以用户需要的功能建立的，所以根据这些基本用例，我们可以抽象出一系列的子系统和包（package/namespace…），这两者最关键的区别在于子系统会隐藏掉实现细节，只留下interface，所以尽量用子系统。借用功能划分的原则就是尽量根据需求中的大功能划分子系统。
        设计子系统内部的类的时候，就要本着高内聚低耦合的原则，UML中类的关系很多，但是比较常用的有四种，依赖、关联、聚合、组合。
        依赖和关联的区分其实很微弱，同样是使用的关系，依赖更注重暂时性，关联则意味着比较长期，所以依赖一般是A在实现某一函数中实例化了一个B，而关联一般是B的指针或引用就是A的一个数据成员。
        聚合和组合的区分也较微弱，同样是包含关系，聚合的关系可以拆断，组合则颇有武侠世界中的剑在人在，剑亡人亡的味道。所以聚合一般是持有引用或指针的实现，组合则直接是对象。
        都是引用和指针，聚合和关联的区别在于逻辑上的意义，聚合是包含，关联是使用！