共计 3507 个字符，预计需要花费 9 分钟才能阅读完成。
软件工程中，随着软件的功能越来越多，相应的软件中代码量也会越来越多，这时软件的复杂度也提高了，相应了该软件也会出现代码重用性、可读性、可扩展性等问题，解决这些问题，就需要用到设计模式了。
在说到具体的设计模式之前，先介绍下设计模式的原则。每种设计模式都是设计模式原则的具体体现。以下说明都是 Java 这种编程语言的
一、设计模式的七大原则
1.1 单一职责原则
对类来说的，即 一个类应该只负责一项职责 。如类 A 负责两个不同职责：职责 1，职责 2。 当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2
1.2 接口隔离原则
一个类对另一个类的依赖应该建立在最小的接口上
举例说明：
类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C 来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法。按隔离原则应当这样处理：将接口 Interface1 拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
1.3 依赖倒转原则
依赖倒转原则 (Dependence Inversion Principle) 是指：1) 高层模块不应该依赖低层模块，二者都应该依赖其抽象 2) 抽象不应该依赖细节，细节应该依赖抽象 3) 依赖倒转 (倒置) 的中心思想是面向接口编程 4) 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类 5) 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成
1.4 里氏替换原则
在面向对象中, 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障题提在编程中，如何正确的使用继承，就需要用到里氏替换原则
里氏替换原则 (Liskov Substitution Principle) 在 1988 年，由麻省理工学院的一位姓里的女士提出的。如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。3) 在使用继承时，遵循里氏替换原则，在 子类中尽量不要重写父类的方法
里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过 聚合，组合，依赖 来解决问题。
1.5 开闭原则
开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则, 一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。当软件需要变化时，尽量 通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
1.6 迪米特法则
迪米特法则 (Demeter Principle) 又叫 最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息
1.7 合成复用原则
合成复用原则尽量使用合成 / 聚合的方式，而不是使用继承
设计原则核心思想
1) 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2) 针对接口编程，而不是针对实现编程。
3) 为了交互对象之间的松耦合设计而努力
二、UML 类图和类与类之间的关系
在上面的介绍中，出现了多张表示类与类之间的图片，它也被称为 UML 类图
UML——Unified modeling language UML(统一建模语言)，是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果,UML 本身是一套符号的规定，就像数学符号和化学符号一样，这些符号用于描述软件模型中的各个元素和他们之间的关系，比如类、接口、实现、泛化、依赖、组合、聚合等
可以发现，要看明白 UML 图，还需要知道类与类之间的关系
1. 依赖关系
只要是在类中用到了另外一个类，那么他们之间就存在依赖关系。如果没有另外一个类，连编绎都通过不了。
代码示例
public class PersonServiceBean {
private PersonDao personDao;// 类
public void save(Person person){}
public IDCard getIDCard(Integer personid){}
public void modify(){Department department = new Department();
}
}
public class PersonDao{}
public class IDCard{}
public class Person{}
public class Department{}对应的类图
2. 泛化关系
泛化关系实际上就是继承关系，他是依赖关系的特例
public abstract class DaoSupport{public void save(Object entity){ }
public void delete(Object id){}}
public class PersonServiceBean extends Daosupport{}对应的类图
3. 实现关系
实现关系实际上就是 A 类实现 B 接口，它是依赖关系的特例
public interface PersonService {public void delete(Interger id);
}
public class PersonServiceBean implements PersonService {public void delete(Interger id){}}类图
4. 关联关系
对象之间一种引用关系，比如客户类与订单类之间的关系。这种关系通常使用类的属性表达。关联可以有方向，即导航。一般不作说明的时候，导航是双向的，不需要在线上标出箭头
代码示例:
// 单向一对一关系
public class Person {private IDCard card;}
public class IDCard{}
// 双向一对一关系
public class Person {private IDCard card;}
public class IDCard{private Person person}5. 聚合关系
聚合关系（Aggregation）表示的是 整体和部分的关系，整体与部分可以分开。聚合关系是关联关系的特例，所以他具有关联的导航性与多重性。如：一台电脑由键盘 (keyboard)、显示器(monitor)，鼠标等组成；组成电脑的各个配件是可以从电脑上分离出来的，使用带空心菱形的实线来表示：
如果我们说 Mouse,Monitor 和 Computer 是不可分离的，则升级为 组合关系
6. 组合关系
也是整体与部分的关系，但是整体与部分不可以分开。是一种强烈的包含关系。组合类负责被组合类的生命周期。也使用属性表达组合关系，是关联关系的一种，是比聚合关系强的关系。
三、设计模式的介绍
设计模式是程序员在面对同类软件工程设计问题所总结出来的有用的经验，模式不是代码，而是某类问题的通用解决方案，设计模式（Design pattern）代表了最佳的实 践。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。设计模式的本质提高软件的维护性，通用性和扩展性，并降低软件的复杂度。
<< 设计模式 >> 是经典的书，作者是 Erich Gamma、Richard Helm、RalphJohnson 和 John Vlissides Design，里面对设计模式更深入的介绍
设计模式分为三种类型，共 23 种 1) 创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模 式。2) 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。3) 行为型模式：模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter 模式）、状态模式、策略模式、职责链模式(责任链模式)。
