设计模式看了很多遍但总是记不住，因此在这里打算通过定义，UML类图，代码示例的方式对这些模式进行一些简单的提炼，便于以后记忆。当然很多人说过设计模式不过是面向对象原则的延伸，只要吃透了六项基本原则（事实上可能更多）便不需要死记硬背这些设计模式。但我应该还没达到这个境界，而且我认为设计模式是前人的一些经验的总结，站在巨人的肩膀上我们总会有更高的生产力。这里主要记录下大家说的最多的GoF的23种设计模式（事实上随着现在web项目和并发编程的发展已不止这些），希望以后当我翻开这篇博客就能重新清晰在我脑海中的关于设计模式的概念。
面向对象的原则
这里简单介绍一下面向对象的一些原则。笔者最先接触OO原则时还是个学生小鲜肉，那时的一本课本上说了个六项基本原则，后来笔者又看到过一个SOLID原则，通过了解发现六项基本原则就比SOLID多了一个迪米特法则（难道是法则不让进原则？）。但现在笔者工作一年后明白原则这东西都是大牛们憋出的大招，没必要纠结是五个还是六个，在经受产品经理的狂风滥炸后，反正越多越好。这里就主要说下常见的六项基本原则。
- 单一职责原则
当需要修改某个类时原因有且只有一个。换句话说就是一个类应该只干好一件事，当需要承担其他的责任时就应该分解这个类。
- 开闭原则
软件应该是对扩展开放，而对修改关闭。这个原则就是说软件应该有良好的结构设计，当需求变更或者增加时，我们只需要扩展新类就可以满足需求，而不需要去修改原有代码，然而这往往是很难办到的。
- 里氏替换原则
对象应该可以在不改变程序正确性的情况下被它的子类替换。这个原则的用处应该不多，更多的情况下我们用的最多的应该是下面的依赖倒转原则。
- 接口隔离原则
认为多个小而专的接口要优于一个大而泛的接口。这其实就像第一个单一职责原则一样，小而专的函数更容易复用，同时也避免了与其他不想干的接口过度耦合。
- 依赖反转原则
正常情况下高层模块会依赖底层模块，而这个原则告诉我们要尽量避免这种情况，使他们都依赖一个抽象，而不是高层组件依赖底层组件。这和针对接口编程而不要针对实现编程很像，但依赖反转可能关注的更深一些。
- 迪米特法则
又称最少知识原则，认为应该减少对象之间的接触，只和朋友说话，也就是为了更好的解耦。每一个类都不应该和太多的的类的耦合，否则你可能只是修改一处地方就会对多处地方甚至整个系统造成影响，同时也会造成代码难以阅读。