深入浅出面向对象分析与设计——学习笔记

       近来因为临近毕业，而且论文已经写得差不多了，故想借点书看以免虚度过多。初翻《深入浅入面向对象分析与设计（中文版）》这本书时，虽然有500多页，但看里面插图不少，于是决定看。前几章介绍的内容感觉有点“吹”，什么伟大的软件由此开始……云云。当然，尽管介绍的知识比较简单，但还是一些原则值得记录的，尽管这些原则原本就在不同的地方接触到过：

       1.软件开发过程：需求->用例->UML表示的类图->实现。分析与设计主要难点在把用例等映射到类图部分，而从类图到实现，只是简单的填空工作，可不需要讨论。有了类图，就可以写单元测试用例了，以单元测试用例此作为验收标准。软件是经常变化的，但变化应该从需求文档开始修改，重复整个过程，而不要期望软件修改只在程序上修改，这是比较规范的开发方式。

       2.软件编码设计时，多考虑将变化和不变的部分分开，即使它们是属于同一个对象，也可以考虑试着把经常变化的属性和不变的属性分开。在一个类中，若有某个方法可能因其它类的改变而面临着改变时，把变化部分提出来，写成函数对象比较好！

       3.UML中的关联（单向"->"箭头）与聚合（单向"◇"箭头）。共同点是二者都需要在类1中持有类2的引用，但区别是：关联是两个相互独立的类，并具有相互之间的组成与包含关系，更多用来表现业务关系（比如在系统中，声音识别器持有一个门的引用，用来控制门的开关，这二者没有组成关系，只有业务关系），而聚合更多表现的是实体之间的关系，是部分组成整体的意思，其中实心的聚合表示该部分不可或缺（比如Person类有Name类的引用，二者是不可或缺的聚合关系）。（看来我以前写过很少错误的UML类图）

       4.OO原则：

• 将变化之物封装起来
• 对接口编码
• 应用程序中的每一个类只有一个改变的理由。

       不过看了几章过后，慢慢就进入状态了，特别是本文中通过一个例子，不断地完善，不断地变化需求要求完善……。此时会发现之前那些可以简单想到的程序设计方式，已经不能满足软件的需求了，而且软件渐渐变得越来越复杂。直至遇到一个我之前也常常困惑的问题：

在一大批子类中有两个子类有些相似，甚至此种情况还在很大其它的子类中出现，如果每个类都确实写一个类，则有很多重复代码，若抽象出这两个类的共同父类则有点不伦不类，但其相似性又不足以抽象成整体各个子类的父类！怎么办？书已经进展到234页了，让我明天再去寻找答案吧。今天先休息了，哈哈。