每一个模式描述了一个在我们周围不断重复发生的问题，以及解决该问题的解决方案的核心。
设计模式不仅仅是一种解决问题的方案，也是一种，更抽象、更高层的沟通和描述的语言。
一般而言，我们关注设计模式的四个方面：
1. 模式名称。一个通用的，用来标识一个设计模式。
2. 问题。清晰地描述了这个设计模式解决的问题，或者是使用这个设计模式的前置条件。
3. 解决方案。这个设计模式是如何实际地解决上面提到的问题的。
4.影响。设计模式最终带来的影响，有好有坏，使用者需要结合实际情况，衡量其中的利弊。一般来说，好处通常是，增加系统的灵活性、扩充性和可移植性。
我们使用1来提高沟通和纪录的效率。结合2和4，我们确定实际遇到的问题和某种模式解决的问题匹配程度，衡量利弊，决定是否使用该模式。参照3，实际使用该模式，设计类图or编码。
设计模式的两种分类标准
1.按照目的来区分。分为，创建型，结构型和行为型。创建型与对象的创建有关。结构型主要处理类或对象的组合。行为型描述了类或对象怎样交互和怎样分配职责。
2.按照范围来划分。指明该设计模式主要用于类还是对象。大部分设计模式都是针对对象的。
我们在定义一个设计模式的时候，首先会给出该模式类型，例如“类创建型”或“对象创建型”。从语义上来说，前者特指，将对象的部分创建工作延迟到子类，后者指，将对象的创建工作延迟到另一个对象。类结构型使用继承机制来组合类，对象结构型则使用对象的组装。
设计或编码过程中常见的问题
1.直接地使用一个实现类来创建对象
这是最常见的情况。我们往往直接使用
Dog dog = new Dog();
这样直接的方式来创建对象。从设计上认为，这种直接的方式，面对以后的变化，会更麻烦一些。所以，建议我们间接的创建对象。相关的设计模式有，抽象工厂，工厂方法和原型模式。
2.对特殊操作的依赖[WIP]
当你为请求指定一个特殊操作时，完成该请求的方式就固定下来了。为了避免把请求写死，你将可以在编译或运行时，很方便地改变响应请求的方法。责任链模式和命令模式。
3.对硬件和软件平台的依赖
硬件一般指的是对系统接口的依赖，软件则指的外部系统或组件的依赖。这是一个耦合松紧的问题，一些设计模式的效果是降低耦合，来达到降低对具体平台的依赖性。相关的设计模式有，抽象工厂和桥接模式。
4.对对象表示或实现的依赖
当使用对象的用户，深刻了解该对象的内部实现细节的话，可能会用到一些“高级”(但是提供方并没有公开)的功能。如果提供方发生了升级或其他导致实现变化的操作，下游用户就不得不修改他的代码。所以，我们需要避免这种连锁式的变化，减少对外暴露的细节。相关的设计模式有，抽象工厂，桥接器，备忘录，代理模式。
5.算法的依赖
“算法”是一个值得提高警惕的东西，它的变化性，显而易见。比如我们经常会先提供一个能work的实现，然后因为不断提高的性能要求而更新的算法。我们需要分清它的接口和实现，确保接口是不易变的。涉及到的设计模式有，建造者，迭代器，策略，模板方法和访问中模式。
6.紧耦合
前面提到的一些问题的根本就是耦合太紧。降低耦合最基础的指导思想就是，分层技术或将耦合抽象(接口化)。
7.扩充功能
当我们面临功能的增加时，一种选择就是继承原来的类，在子类中实现新的功能。这是一种不好的方式。继承的方式，并不能很好的封装父类的实现细节，这将导致子类和父类的耦合大概率增加。对于这种功能的扩充，常用的设计模式有，桥接器，责任链，复合，装饰器，观察者和策略模式。
8.修改原有的功能
一般来说，我们的设计应该坚持，“不支持修改，只支持扩展”。但是，实际情况下还是会需要修改一个已有的功能。为了避免修改之后，隐藏的或者连锁式的影响，可以采用一些设计模式，比如，适配器，装饰器和观察者模式。
