我们首先需要了解什么叫模式：
简而言之：人们在自己的环境中不断发现问题和寻找问题解决方案的同时，发现不同问题的背后其实包含着共同的本质，这些本质就是所说的模式
因此模式具有代表性
在面向对象领域中最早提出模式化方法研究的是“四人帮”（Gang of four 简称GoF，Erich Gamma,Richard Helm,Ralph Johnson,John Vlissides）,在1995年出版了
《Design Patterns》, 但模式的真正起源是出自于建筑工程大师Christopher Alexander的著作
在开发的一个软件系统时我们必须解决的两个核心问题是：可维护性（Maintainability）和可复用性（Reuseability）;帮助我们解决这两个问题的最好方式就是使用设计模式，
但在学习和使用设计模式的时候，我们不能一味的照搬照抄，我们要有我们自己的思维，怎么办呢？这是我们就需要了解的熟知指导设计模式形成的设计原则：
在讲解设计原则前我们还要就两个核心问题进行深入的讨论：
1.可维护性
有几年开发经验的人都会有这个感觉：就是花在一个系统上的维护时间会远远多于该系统的开发时间。并且据统计国内外失败的项目高达60%以上；
下面引用Rober C.martin的指导，导致一个系统的维护性低主要有四个原因：
1).过于僵硬：在系统中加入一个新性能，不仅仅意味着加入一个独立的新模块，而且因为这个新性能会波及很多其他的模块，这样导致可能一个简单的功能却遥遥无期
2).过于脆弱：在系统中修改一处地方，往往会导致没有什么关系的另一个地方发生故障
3).复用率低：有时我们会发现一段代码，函数，模块所做的事可以在新模块中进行重用时，但是发现这些已有的代码总是依赖一些其他的东西，很难将他们分开，最后你放弃了重用，还是寻找使用ctrl+s,v
4).粘度过高：
设计的目标：
1).可扩展性：新的性能可以很容易的加入到系统中去而不会引起其他的问题，即“过于僵硬”的反面
2).可插入性：很容易的将一个类抽出来同时将另一个有同样接口的类加进去，即“粘度过高”的反面
3).灵活性：可以允许代码的修改平稳的进行，而不会波及到其他的很多模块，即“过于脆弱”的反面
面向对象设计原则：
1)："开闭" 原则（Open-Closed Principle, OCP）：
一个软件实体应当对扩展开放，对修改关闭（software entities should be open for extension,but closed for modification），即类在不被修改的前提下被扩展，因此也称“可变性封装原则”。
2):里氏代换原则（Liskov Substitution Principle, LSP）：
如果对类T1的每个对象o1,都有类T2的对象o2，使得包含T1的所有程序P在所有对象o1都转化为o2，程序P的行为没有变化，那么类T2是类T1的子类，即父类的行为一定适合于子类，但反过来的代换不成立。若类A与类B之间的关系违反了里氏代换原则，可以再以下两种重构方案中选择一种：
①创建一个新的抽象类C，作为A和B的超类，将A和B的共同行为移到C中，从而解决A和B行为不完全一致的问题；②从B到A的继承关系改为委派关系。
3):依赖倒转原则（Dependency Inversion Principle, DIP）：
高层模块不应该依赖于低层模块，抽象不应该依赖于细节
4):接口隔离原则（Interface Segregation Principle, ISP）：
使用多个接口比使用单一接口要好。从客户端的角度来说：一个类对另一个类的依赖应该建立在最小的接口之上的，如果客户端只需要某一个方法的话，应该向客户端提供该方法，而不要提供不需要的方法，提供接口以为着向客户端做出承诺，但过多的承诺会给系统维护造成不必要的负担。
5):组合/聚合复用原则（Composition/Aggregation Reuse Principle, CARP）：
尽量使用组合，聚合，而尽量不要使用继承。
6):迪米特法则（Law of Demeter, LoD）：
一个对象应该尽可能少的了解其他对象，即只与直接的朋友通信，不跟陌生人说话。
7):单职责原则（Single Responsibility Principle, SRP）：
一个类应该只有一个引起它变化的原因，如果一个类有多个引起它变化的原因，则应该把它拆分为多个类。
面向对象设计模式：
根据设计原则，