OOAD

软件危机<60年代>（特征）:
1） 软件开发周期无法确定
2） 软件开发成本越来越高，甚至无法控制
3） 产品质量不高，产品的功能无法满足客户的需求，项目容易失败
4） 当时程序员的技术，沟通能力等相关能力参差不齐，导致产品质量不高
5） 软件产品维护困难，（例如：程序员的技术以及个人习惯等因素）
6） 当时软件开发，不注重文档，软件缺少适当的文档资料

软件开发中，经典开发步骤：
瀑布模型：
1） 可行性分析
2） 需求分析（OOA） 面向对象 面向过程
3） 软件设计（OOD） 面向对象 面向过程
4） 编码（OOP） 面向对象 面向过程
5） 测试
6） 交付产品
7） 维护
存在的问题：如果需求发生变更，只能发生在极早期，越晚代价越大

改进方案：迭代 + 瀑布模型
1） 计划驱动 （迭代期内不进行需求变更，如果有需求变更将在下一周期内实现）
2） 敏捷开发

一个软件设计的优劣
评价标准：
1） 用户所提的业务功能是否有全面覆盖
2） 前期所设计的文档，有可读性高不高，能否被人快速理解
3） 软件设计中，覆盖到的类、包、接口等各种组件，复用性是否较强
4） 软件开发后期，对于业务需求的变化，业务功能的扩展性高不高
5） 软件开发中或开发后期，维护能力强不强

软件开发过程中，是否满足“高内聚（一个类或一个方法，只能做一件事），低耦合（类和类之间的关系紧密程度越低越好）”

设计原则：
1、单一职责
“一个类只干一件事”，这是软件设计中高内聚中最重要的一点。一个类只有一种职责，这个职责需要根据类的对象来确定。例：在学校系统中，学生这个对象，只需要关注学习相关的东西，而不应该关注其他。

在设计类时，类中的每个属性、方法必须跟这个类的职责有直接关系。

类的职责单一，也是一种降低耦合度的手段，对象的职责越少，耦合关系越低，代码越容易复用，这一原则同样适用于方法。

2、开闭原则
开闭原则是所有的原则的核心，其他任何原则最终的目的都是为开闭原则所服务，是指组成程序的代码，应该对功能的扩展是开放的，对功能的修改是关闭的

表现为：
对功能的扩展开放：对于一个系统而言，业务功能可能随时改变，该原则就会支持我们扩展新的功能，满足用户需求

对功能的修改关闭：当在扩展新功能的时候，不能对之前所设定的功能进行修改

3、里氏替换原则
定义：子类可以出现在父类出现的任何地方，并且父类之前定义的规则不会发生任何改变。
作用：为了维护现有的继承体系。
这个原则是开闭原则的一种体现，保证子类在新增功能的时候，不会改写父类所定义的方法，从而维护现有的继承体系

4、依赖倒转原则
软件设计中,将两个模块之间的依赖关系倒置为依赖抽象类或接口
表现为:
1） 上层模块不应该直接依赖下层实现，而应该依赖于下层的抽象
2） 每一单独的层次，抽象不该依赖于细节，而应该是细节依赖于抽象

5、组合/聚合复用原则
用来解决“代码”的复用问题（包括继承、组合/聚合）
组合/聚合这种方式跟多强调的是部分与整体的关系，组合耦合度较高，聚合耦合度较低
组合/聚合优点：
1） 采用面向接口编程来实现类与类之间的松散耦合
2） 接口是抽象的，不会面向细节操作
3） 面向接口编程比面向细节编程耦合度低
4） 面向接口编程接口的实例程序运行过程中动态绑定的，灵活性较高

继承优点：
1） 父类所定义的属性和方法，子类继承不需要重复定义
2） 定义上来说，子类要重写或扩展新的方法，不会对父类产生影响
缺点：
1） 继承会破坏包装，父类对子类是完全透明的，所有的子类以及在往下的子类知道超类的方法
2） 父类如果发生变化，子类也会跟着改变
3） 继承关系，使用extends在编译期间就可以确定下来，这种关系的建立，称为“静态关系”，不具备灵活性

6、接口隔离原则（ISP）
当一个类要实现一个接口时，原则上，这个接口只实现一种功能（承担一种职责）
当接口继承接口时，这一原则同样适用

7、迪米特法则（LOD）<最少知道原则>
在定义类或实现类的方法时，尽量只与类的朋友进行交互