Java设计模式：设计模式基础知识和原则

设计模式

概念

模式是在某种情景下(Context)下，针对某问题的设计的某种解决方案。

• 情景：是应用某个模式的情况。这应该是会不断出现的情况。
• 问题：是你想在某情景下达到的目标，但也是某种情景下的约束
• 解决方案：是你所求的一个通用的设计，可用来解决约束，达到目标。

分类

模式可以分为以下三种不同的类别：创建型、行为型和结构型。

• 创建型：创建型模式涉及到对象实例化，这类模式都提供一个方法，将客户从所需要的实例化对象中解耦。
• 行为性：只要是行为行为设计模式，都涉及到类和对象如何交互以及分配职责。行为设计模式的目的——对象之间的沟通与互联。
• 结构性：结构性设计模式可以让你把类或者对象组合到更大的结构中。结构型模式用来描述类和对象如何被组合以建立新的结构或者新的功能。

分类细则

• 二、创建型
  • 1. 单例（Singleton
  • 2. 简单工厂（Simple Factory）
  • 3. 工厂方法（Factory Method）
  • 4. 抽象工厂（Abstract Factory）
  • 5. 生成器（Builder）
  • 6. 原型模式（Prototype）
• 三、行为型
  • 1. 责任链（Chain Of Responsibility）
  • 2. 命令（Command）
  • 3. 解释器（Interpreter）
  • 4. 迭代器（Iterator）
  • 5. 中介者（Mediator）
  • 6. 备忘录（Memento）
  • 7. 观察者（Observer）
  • 8. 状态（State）
  • 9. 策略（Strategy）
  • 10. 模板方法（Template Method）
  • 11. 访问者（Visitor）
  • 12. 空对象（Null）
• 四、结构型
  • 1. 适配器（Adapter）
  • 2. 桥接（Bridge）
  • 3. 组合（Composite）
  • 4. 装饰（Decorator）
  • 5. 外观（Facade）
  • 6. 享元（Flyweight）
  • 7. 代理（Proxy）

设计原则

1. 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。

2. 针对接口编程，而不是针对实现编程

"针对接口编程"真正地意思是“针对超类型(supertype)编程”。可以更明确的说成“变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口”

3. 多用组合，少用继承

使用组合构建系统具有很大的弹性，不仅可将算法封装成类，更可以“在运行时动态地改变行为”，只要组合的行为符合正确的接口标准即可。

4. 为了交互对象之间的松耦合设计而努力

松耦合的设计之所以能够让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的依赖性降低到了最低。

5. 类应该对扩展开发，对修改关闭

我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可以搭配新的行为。这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。

6. 要依赖抽象，不要依赖具体类（依赖导致原则）

不能让高层组件依赖于低层组件，而且，不管高层组件还是底层组件，“两者”都应该依赖于抽象。

7. 最少知识原则：只和你的密友谈话

不要让太多的类耦合在一起，免得修改系统中的一部分，会影响到其他部分。如果许多类相互依赖，那么这个系统就会变成一个易碎的系统，他需要花许多成本维护，也会因为太复杂而不容易被其他人了解。

8. 好莱坞原则：别调用（打电话）我们，我们会调用(打电话给)你。

在好莱坞原则下，我们允许底层组件将自己挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些底层组件。换句话说，高层组件对待底层组件的方式是”别调用我们，我们会调用你们“。

9. 单一责任原则：一个类应该只有一个引起变化的原因。

我们知道要避免类内的改变，因为修改代码很容易造成许多潜在的错误。如果有一个类具有两个变化的原因，那么这会使得将来该类的变化几率上升，而当它正在改变的时候，你的设计中同时又两个方面讲会受到影响。