设计模式复习（一）

1.软件危机的表现：

• 软件成本日益增长
• 开发进度难以控制
• 软件质量差
• 软件维护困难

2.软件危机的原因

• 用户需求不明确
• 缺乏正确的理论指导
• 软件规模越来越大
• 软件复杂度越来越高

3.如何克服软件危机

重用的设计方法、多维管理模式

4.设计模式概要

设计模式四要素：

• 模式名称（Pattern Name）
• 问题（Problem）
• 解决方案（Solution）
• 效果（Consequence）

设计模式分为三类：

• 创建型模式（Creational Patterns）
  • 是类在实例化时使用的模式，当一些系统在创立对象时，需要动态地决定怎样创立对象，创立那些对象。创立型模式告诉我们怎样构造和包装这些动态的决定。
• 结构性模式
  • 描述类和对象怎样结合在一起成为较大的结构。
  • 结构性模式描述两种类型：类与类的实例
• 行为型模式
  • 描述类和对象之间的作用

23种设计模式总览，加粗的为课上学过的

	创建型	结构型	行为型
类	工厂方法（Factory Method）	适配器（Adapter）	解释器（Interpreter）、 模板方法（Template Method）
对象	抽象工厂（Abstract Factory）、 建造者（Builder）、 原型（Prototype）、 单例（Singleton）	桥接（Bridge）、 组成（Composite）、 装饰（Decorator）、 外观（Facade）、 享元（Flyweight）、 代理（Proxy）	责任链（Chain of Responsibility）、 命令（Command）、 迭代器（Iterator）、 中介者（Mediator）、 备忘录（Memento）、 观察者（Observer）、 状态（State）、 策略（Strategy）、 访问者（Visitor）

其中：

• 创建型模式关注对象的创建过程，将对象的创建和使用分离，从而在使用对象时无需关心对象的创建细节，从而降低系统的耦合度。关注三个问题：创建什么对象，对象由谁来创建，何时创建对象。
• 结构型模式关注如何将类和对象进行组织，使之协同工作，高效的完成工作。结构型模式又分为类结构型模式和对象结构型模式。
  • 类结构模式由多个类通过组合或继承实现关系 完成功能，不过老师上课说了，一般项目中用继承实现关系，除非有清晰的结构关系，否则不要使用继承泛化，Java不允许多继承（一个类只能有一个父类，不允许有多个父类，但一个类可以被多个类继承）也印证了这一点，来防止继承机制的滥用。
  • 对象结构型模式是通过类和对象的组合，通过关联关系，在一个类种定义另一个类的实例对象，然后通过该对象调用相应的方法。采用此种模式较为广泛。
• 行为型模式关注系统中对象之间的交互，明确它们的职责划分，重点是对象行为型模式。

5.设计模式要坚持的原则：

• 单一职责原则（Single Responsibility Principles）

  • 体现的是内聚性（一个模块的组成元素之间的功能相关性）
  • 就一个类而言，应该仅有一个引起它变化的原因
  • 每一个职责都是变化的一个轴线（an axis of change）
  • 功能不变的类，可以适当集中

• “开-闭”原则（Open-Closed Principles, OCP）

  • 软件实体（类、模块、函数等）应该是可扩展的，但是不可修改。

    • 具有僵化性设计臭味的软件就违反了OCP原则：程序中一处改动会引起连锁反应，导致一系列相关模块的改动
    • 实际开发过程中，我们会使用各种方法尽量接近这个目标

  • 对于扩展是开放的

    模块的行为是可扩展的，我们可以根据需求的变化来改变模块的功能

  • 对于修改是封闭的

    对模块行为进行扩展时，不必改动模块的源代码或二进制代码（需要重新编译即为修改）

  • 如何做到？

    抽象：把一个功能的通用部分和实现细节清晰的分离开来；通过派生（继承）来扩展功能

  • 面向对象设计的核心

• 里氏代换原则（Liskov Substitution Principles, LSP）

  • 是对开闭原则的补充
  • 实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范
  • 子类型必须能够替换掉他们的基类型，基类型不一定能替代子类型（基类型的范围大）。
  • 只有子类能完全替代父类才能保证抽象父类的复用和扩展。
  • 基类内部的方法不能含有对子类类型的判断，也就是说，如果子类的添加/改变会导致我们改变基类，这就意味着有设计缺陷。

• 依赖倒转原则（Dependency Inversion Principles, DIP）

  • 高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
  • 抽象不应该依赖于细节，细节应该依赖于抽象
  • 推论：要针对接口编程，不要针对实现编程。
  • 如果高层依赖于底层，底层变化会导致高层变化；底层和细节往往会不停变化，高层不应该跟着变化；高层的变化往往来自于需求，这种策略型的变化也不应该影响底层和细节–>谁也不要依赖谁，都依赖于接口。

• 接口隔离原则（Interface Segregation Principles, ISP）

  • 胖接口：类的接口不是内聚的，胖接口应该分解->将类分解

• 迪米特法则（Law of Demeter, LoD）

  • 最少知识原则：一个对象应当对其他对象有尽可能少的了解（低耦合）
  • 对于被依赖的类来说，无论逻辑多复杂，都尽量地将逻辑封装在类的内部
  • talk only to your immediate friends
    • 朋友：
    • 直接朋友：出现在成员变量、方法参数、方法返回值中的类

• 组合/聚合复用原则（Composition/Aggregation Principles, CARP）

  尽量使用合成/聚合，而不是使用继承

  • 合成表示一种强的拥有关系，体现了严格的部分和整体的关系（人和胳膊），关系用实心的菱形+实线来表示
  • 聚合表示一种弱的拥有关系，体现的事A对象可以包含B对象，但是B对象并不是A对象的一部分（人和人群），关系用空心的菱形+实线来表示–个体和群体
  • 使用继承的情况：
    • 子类是父类的一个特殊种类，而不是父类的一个角色
    • 永远不会出现需要将子类换成另外一个类的子类的情况
    • 子类具有扩展父类的责任，而不是置换掉或注销掉父类的责任。如果一个子类需要大量的置换掉父类的行为，那么这个类就不应该是这个父类的子类。

另外：复习UML类图