1、设计模式之开篇。
很长时间没有写文章了，前段时间写的c#语法糖分享得到有很多朋友支持，这个也使得我有信心继续分享下去，在这里非常感谢大家！这次开始给大家分享一下设计模式，我个人觉得设计模式也对于我们提高个人技术水平来说也是一个必不可少的知识点，最近我有重新温习了一下设计模式，今天把我学习时的心得给大家分享一下。
有些朋友会分不清设计模式是什么，它是框架吗？在这里我简单的分享一下我的个人理解，有些不对地方请大家谅解和指正，废话不多说，直接进入主题：
设计模式和框架的区别：
设计模式是针对某一类问题的最佳解决方案，而且已经成功应用于许多系统的设计中，它解决了在某种特定情景中重**生的某个问题，因此，可以这样定义设计模式：“设计模式是从许多优秀的软件系统中总结出的成功的可复用的设计方案。
框架不是模式，框架是针对某个领域，提供用于开发应用系统的类的集合。程序设计者可以使用框架提供的类设计一个应用程序，而在设计应用程序时可以针对特定的问题使用某个模式。一个框架往往会包括多个设计模式，他们是面向对象系统获得最大复用的方式。
设计模式分类如下图所示：
这次分享主要给大家分享设计模式和框架的区别及设计模式的分类，下次开始分享具体的设计模式。希望给大家带来帮助！谢谢。
2、设计模式之设计原则。
我们这次分享讲解具体设计模式之前给大家分享一下设计模式原则，很多人有可能会疑惑为什么要用设计模式啊？设计模式有什么好处，设计模式就是很多前辈们在他们设计软件时在大量的编码中总结出来的一些思路，因为大家都知道有一个好的框架思路是一个软件成功与否的关键。个人理解设计模式是面向对象的更优的**风格及封装。
我们平时编码时会遇到如下一些问题：
1）系统僵化，不可修改或不可扩展（修改难或者扩展难）。
2）过分复杂或者重复**太多，往往看**时不知道从**看起，也不知道程序会跑到**。
3）不可复用，公共部分剥离不出来，只能到处拷贝。
4）不够稳定：经常出错，然后修改，再出错，继续改。
5）系统不稳定，最后程序员自己都不敢相信自己写的系统。
我个人是编码中也遇到以上的这些问题，不知道大家有没有遇到过啊。
为了解决这些问题在面向对象编码过程中规定一些规则，这就是设计模式原则，对于设计模式原则也有很多说法，但是我个人学习的有六项，分享给大家：
1）开放-封闭原则（open closed principle):简称ocp ：该原则的核心思想就是想说明软件应该是可以扩展，而不可以修改的。
对扩展开放：有新的需求或改变时可以对软件进行扩展，以适应新的情况。
对修改封闭：类一旦设计完成就独立工作，而不再对类进行任何修改，但并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的**片段了 。
实现方式：抽象、多太、继承、接口。
给大家简单的计算器例子：
调用**如下：
输出结果如下：
以上**从功能上来说也能实现，但是我们可以发现如果想在添加一个两个数字相除的功能，必须修改normal方法，如果过几天客户还需要添加平方根之类的需求还需要修改，无限的修改，在这里编码简单，所以出错也会很少，如果该功能要有上千行**的话在添加功能时会带来很大的麻烦，还会破坏以前的**，有一个人不小心把以前的**动了一下，把别的功能给影响了，导致以前的测试通过的**还需要重新测试。
下面在看看这个例子：
以上**类图如下：
客户端调用**如下：
输出结果：计算结果都一样，但是该方法如果遇到修改需求，添加一个数字相除时不需要修改以前的**，只需要在扩展一个相除方法。
**类图如下：
从类图可以看出以前的**不需要修改，添加一个方法即可实现。
总结：从上面的两个例子的对比能明显的看出来好处，所以开放封闭原则不是说不能修改任何**，这样的话新的需求没法弄，所以该原则其实是针对方法需要抽象变化，对于客户端来说抽象编码，这样会尽可能的减少**的修改，但是不会失去扩展的功能，但是需要注意的是抽象也不能滥用哦，要适当的使用。
单一职责原则（singleresponsibilityprinciple）简称srp：该原则的核心思想是一个类最好只做一件事情，只有一个引起变化的原因。
单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。
单一职责原则带来的好处：
1）类的复杂性降低，实现什么职责都有清晰明确的定义。
2）可读性高，大家想想50行**可读性高呢还是1000行**可读性高呢？
3）可维护行高，这个应该不用我说。
4）变更引起的风险降低，每一个类负责一个一件事情，变更该类对其他类的影响很少。
这里举一个简单的例子：
从上面例子中可以看出来modem接口明显有两个职责：连接管理和数据通信，所以应该按照职责分离出来。
注意：单一职责不是从类的功能点多少来划分的，而是从类引起变化的原因来分的，一个类引起变化的原因只有一个，如果一个变化引起多个职责发生变化，那么这些职责应该被封装到一个类。
接口隔离原则（interface segregation principle ），简称isp：该原则核心思想就是客户端不应该被强迫实现一些不会使用的接口，应该把胖接口中的方法分组，然后用多个接口来代替，每一个接口只服务与一个子模块。这个跟上次分享的单一职责原则类似。
设计接口隔离原则的目的：当我们设计应用程序时，如果一个模块包含多个子模块，那我们应该正对该模块抽象。设想该模块由一个类实现，我们可以把系统抽象成一个接口，但是我们想要添加新的模块扩展程序时，如果要添加的模块只包含原来系统的一些子模块，那么就强迫我们实现该接口的所有方法，这样的接口被称之为胖接口或者被污染的接口。
我们可以把这定义概括为一句话就是建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。
看到这里大家有可能要疑惑了，这与单一职责原则不是相同的吗？错，接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”,专门的接口指什么？
就是指提供给每个模块都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。
设计模式入门学习工厂模式
先读一本设计模式入门书，深入浅出设计模式，之后再拜读一下gof设计模式。工作也有两年时间了，说设计模式接触的应该比较多了，只是一直没有进行系统的整理。说起来，刚入职做webkit这让我有一个比较高的技术起点，技术视界也比较宽广。抓时间系统过一遍设计模式，下编码的艺术。工厂模式 为创建对象提供过渡接口...
设计模式学习笔记 命令模式
命令模式将请求封装成对象，以便使用不同的请求 队列或日志来参数化其他对象。命令模式也支持科撤销的操作。提供了用统一方法执行不同行为的简单机制。允许在运行时改变所处理的请求，以及如何处理请求。仅仅需要很少的 实现。当条件调度程序已经足够的时候，会增加设计的复杂度。命令模式将发出请求的对象和执行请求的对...
设计模式学习笔记
创建型模式。抽象工厂生成器工厂方法原型单件适配器桥接组合装饰外观享元 职责链。abstract factorybuilderfactory 可产生一系列类的对象复杂步骤逐步创建对象。拷贝对象原型。全局一个实例，一个访问点对象结构型模式。将一个类的接口进行转换后兼容，解决接口不匹配。将抽象部分与实现部...