设计模式修炼之路-初识设计模式
作为一个程序员我们经常能听到设计模式这个词，面试的时候也经常会被问到设计模式相关的问题，那么设计模式到底个什么？为什么要用设计模式？什么场景下要用到设计模式，应该使用哪种设计模式？如果有这些问题那就跟我一块来学习设计模式吧。
什么是设计模式？
我们平时所说的设计模式准确的来说应该称之为面向对象的设计模式。因此，设计模式适用于java、python、c#、.net等等一切面向对象的语言。那有没有面向过程的设计模式呢？答案肯定是有的，只不过没人系统的总结出来，没有为人所熟知，没有达成共识，因此也就没有广为流传。本人对面向过程开发的语言也不甚熟悉，因此在此也不做讨论。接下来我们看看什么是设计模式？设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。简单来说就是为了提高代码可读性、合理性、可靠性总结出来的已经被多数人认可并达成共识的代码设计经验。
设计模式的分类
我把百度脑图的地址分享出来如果模糊的可以点进去查看
看了上面的图是不是有少许疑惑，明明23种设计模式为什么一下蹦出这么多，看完上面的设计模式定义我们应该知道设计模式也是总结出来的，所谓的23种是广为人知并且用到的比较多的，去除思维导图中J2EE模式中的8种和红色标注的过滤器模式、空对象模式刚好剩下的就是常说的23种设计模式，因为本人主要用的开发语言是java所以还想聊一聊J2EE的模式，所以也就一并列了出来。
接下来先说除J2EE模式外的三种分类模式
1.创建型模式
对于面向对象的编程语言我们平时用到的最多是可能就是创建对象，顾名思义创建型模式分类下的设计模式都是与创建对象相关的。我们在创建对象时通常会根据不同的逻辑来创建对象，而创建型模式分来下的设计模式说白了就是为了隐藏创建逻辑，减少我们在创建对象时写的一些逻辑代码。
2.结构型模式
面向对象的三大特性封装、继承、多态是不是深入每个面向对象语言开发者的脑海。那么继承的优缺点又是什么呢？如果你能不假思索的说优点是提高了代码的复用性，缺点是提升了代码的耦合度，那么你一定是甲方需求无限变动的受害者，哈哈！！当然，导致代码耦合度增加的原因也是各种各样的。而结构型模式分类下的设计模式要解决的就是通过聚合、组合对象接口等方式降低继承所带来的耦合度。
3.行为型模式
通常我们的业务功能无法通过单一的类或对象来实现，而牵扯到多对象或者类协同工作通常代码的复杂度和耦合度也会提升。行为型模式分类下的设计模式主要是为了更好的分配对象之间的职责和关系。行为型模式又分为类行为模式和对象行为模式。类型行为模式通过继承的方式来分配行为，对象行为模式通过对象聚合、组合的方式来分配行为，因此对象行为模式更加灵活。行为型模式下除了模板模式和解释器模式是模式属于类行为模式外其他9种都属于对象行为模式。
4.J2EE模式
J2EE标准可以说是为了解决C/S架构，迎合B/S架构而生的标准，J2EE模式分类下的设计模式是由Sun Java Center 鉴定的，学习这些设计模式，有助于对J2EE标准的理解。
设计模式的六大原则
这里只简单的讲讲六大原则，就不展开再讲，展开讲的话每个原则都能写一大篇，后续再单独讲。所有原则的主要目的就是为了降低耦合、降低耦合、降低耦合。理解其目的就行。
1、开闭原则（Open Close Principle）
对扩展开放，对修改关闭。简单的来说就是我们的程序拓展性要强，当程序功能需要扩展时我们不能去修改已有的类（对修改关闭），而是通过增加相关类来扩展程序功能（对扩展开放），从而实现热插拔效果。我们可以通过抽象化来实现开闭原则。开闭原则是最基础的设计原则，其他五个原则都是开闭原则的具体形态。
2、里氏代换原则（Liskov Substitution Principle）
任何基父类可以出现的地方，子类一定可以出现。简单说就是子类可以扩展父类功能但是不能改变父类原有功能，这样才能真正做到基类的复用。有的同学可能转念一想不对啊，那子类重写父类方法不就违背了里氏替换原则。是的，确实是违背了里氏替换原则，一旦重写耦合度不就又增加了，因此我们要尽量减少重写父类方法，通过增加基类让原来的子类和原来的父类 通过聚合、组合、依赖关系来降低耦合。
3、依赖倒转原则（Dependence Inversion Principle）
高层模块不应该依赖低层模块，两者都应该依赖其抽象。抽象不应该依赖细节。细节应该依赖抽象。简单来讲就是我们常说的面向接口编程（OOD）。
4、接口隔离原则（Interface Segregation Principle）
使用多个隔离的接口，比使用单个接口要好。这里的接口是广义上了接口，可以使接口、抽象类、实体类。客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。
5、迪米特法则，又称最少知道原则（Demeter Principle）
一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。这个相对好理解就是尽量减少类之间的依赖，一句话总结：少和陌生人说话。
6、合成复用原则（Composite Reuse Principle）
尽量使用合成/聚合的方式，而不是使用继承。这个原则简单明了能不用继承就不用继承。
正文到此结束
