看完了，就全忘了，不总结就等于没看！所以大概的总结了。

大话设计模式

大话设计模式中将近三十种模式，是将我们原来的代码框架思路转变成另一种思路。代码和生活是一样的，当我们发现重复的去做一件事情的时候就会思考是否会有捷径有效率的完成，而在程序中当大量重复的代码出现时，我们就自然想到类、抽象、接口，而又是如何让每一类独立性更强，如何达到最佳的分类效果，这就要靠我们在学习中发现和探索。而设计模式是我们思路的指导，让我们对面向对象编程更加深刻的认识。而最终的目的是我们设计出易维护、易扩展、易复用、灵活性好的程序。

简单工厂模式---计算器

在该模式中就是把我们平时写计算器的代码进行模块化，是从宏观上设计，将原来我们只值注重在主函数中写代码转到把大体相同的事物抽象为类。抽象出运算类抽象类，并且加法类、减法类、乘法类、除法类继承该抽象类。为了避免更多的重复操作，考虑用一个单独的类来做这个创造实例的过程，从而增加了运算工厂类，从而使客户端代码进一步简洁。

策略模式---商场收银

在这个模式告诉我们代码不但要实现单一的功能，而是要想到这个程序的复用，和扩展性，代码是否复杂和重复的太多，软件的健壮性和效率问题。

一个简单的根据单价和数量来计算总的钱数。在这里提出的是是增加打折之后怎样去实现。

用我们开始所学的简单工厂模式，是把打折方式分为类，并且继承策略这个超类。而在具体的策略类中为了传入具体的策略对象另一方面是为了调用策略中的方法。这样只让客户端识别了一个cashContext类，而用简单工厂要识别CashSuper和CashFactory两个类。

策略模式是一种定义一下列算法，从概念上来看，所有这些算法都是相同的工作，只是实现不同，它可以用相同的方式来调用所有的算法，减少了各种算法类与使用算法类之间的耦合。

单一职责原则---手机拍摄UFO

小菜要拍摄UFO，从而想到摄像机和我们平时使用的手机上带的摄像头的不同。单一职责原则：一个类，应该仅有一个引起它变化的原因。软件设计真正要做的很多，就是发现职责，并把这些职责相互分离。

开放封闭原则---考研和工作

从小菜考研和工作要做到同时准备来说，提出了开放封闭式原则，就是说软件实体（类、模块、函数）等应该可以扩展，但是不可以修改。对于扩展是开放的，对于更改是封闭的。要多扩展少修改，就像开始所学的简单工厂模式一样，在原来的代码基础上是通过增加代码（类）来进行的，而不是通过改现有的代码。

依赖倒转原则---修电脑和收音机

在修计算机主机的时候发现各个插槽接口是独立的接口，并且对与有的插槽可以扩展，例如内存不够可以扩展，硬盘不够可以使用可移动硬盘，所以总结出抽线不应该依赖于细节，细节应该依赖于抽象，要针对接口编程，不要针对实现编程。

里氏代换原则---依赖了接口和抽象类就不怕了

子类型必须能够替换其父类型。只有当子类可以替换掉父类，软件单位的更能不受影响，父类才能真正的被复用，而子类也能够在父类的基础上增加新的行为。

装饰模式---衣服种类和要打扮的人分离

可以动态的实现“穿衣服”，为已有的功能动态的添加更多的功能。

代理模式---戴励代卓贾易追娇娇

把送礼物抽象出接口，让代理和实际的追求者来实现接口中的方法，而代理和追求者之间是相互依赖的关系。

工厂方法模式---雷锋工厂

工厂方法模式是简单工厂模式的抽象和扩展。工厂方法模式是由客户端来决定实例化哪一个工厂实现运算类。在简单工厂类中要增加功能是是改动的是工厂类，而在工厂方法模式要改的就是客户端了，从客户端中实例化工厂类来进行调用。

原型模式---简历复印（浅复制）

原型模型是从一个对象再创建另一个可定制的对象，而且不需要知道任何的创建细节。。Net在System命名空间中提供了ICIoneable接口，继承这个接口来实现的复制，这个接口中的方法Clone（）。

模版方法模式---把试题和答案分离

模版方法通常是把不变的行为搬移到超类中，去除子类中的重复代码来体现优势。

迪米特法则---办事找部门（找低层次的模块）

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发。

外观模式---对基金的操作和股票的类型分离

增加外观类来减少接口，使客户端简单。

建造者模式---建造小人

把构造小人和表示小人分开。

观察者模式---老板和秘书通知员工

定一个了通知者和被通知者接口，具体的通知者和被通知者来分别实现这个接口，在抽象的通知者接口中定义抽象的方法这样以便可以动态的添加和删除被通知者。当一个对象的改变需要同事改变其他对象的时候应该考虑到使用观察者模式。

抽象工厂模式---数据库的更换

与工厂模式不同的是，的业务逻辑层只有一个类，而抽象工厂模式又添加了IDepartment的抽象接口和类。简单工厂模式、工厂模式和抽象工厂模式，三个模式比较来就好理解了。

状态模式---把不同的工作状态分离出来

当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。感觉状态模式和前面的策略模式有异曲同工之妙。在这里面用的是把Context类作为了状态类state的抽象方法来使用的，并在具体的状态类中把下一状态赋值了。

状态模式的好处是将与特定状态相关的行为局部化，并且将不同的行为分割开来。

适配器模式---在NBA需要翻译

适配器模式，将一个类的接口转换成为客户希望的另外的一个接口。就是在翻译者类中实例化姚明，并在方法中进行“翻译”。

备忘录模式---游戏进度

在不破坏封装型的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以对这个状态进行恢复了。也就是在备忘类中传递一个发起人类的state字符串。

组合模式---分公司和部门

将对象组合成树形结构来表示“整体和部分”的关系。声明一个抽象的Componet类管理子部件和叶子部件，该抽象类中定义增加、移除和显示的抽象方法，叶子类和枝干类分别继承该抽象类。

迭代器模式---售票员遍历车上所有的人

定义了一个迭代器抽象类、要迭代的抽象类、具体的迭代器、具体的要迭代的类。在具体的迭代器类中声明要迭代的类，在具体的聚集类中实例化一个具体的要迭代的类，并将当前的聚集类传递到具体的迭代器的类中，在迭代器的类中作为构造函数进行初始化。

单例模式---类的计划生育

是通过的改变类的构造方法来实习的，因为对于类的构造方法，如果不声明类的构造方法，系统则默认无参的构造方法，如果显示的定义了，默认的构造方法就失效了。

单例模式是保证一个类仅有一个实例，并且提供一个访问它的全局访问点，把默认的构造方法设置为私有的，通过定义该类中的一个方法来进行实例化，再在客户端判断是否重复实例化。

桥接模式---不同手机对软件的兼容问题

合成聚合原则：是尽量使用合成/聚合，尽量不要使用类的继承。桥接模式就将抽象部分和它的实现分离，使他们都可以独立的变化。定义手机品牌和手机软件两个抽象类且他们之间是聚合的关系，具体手机品牌类和具体的游戏类再去继承他们。

命令模式---烤肉请求烤肉师傅实现

抽象命令类，在该类中实例化一个具体的烤肉者和一个抽象的命令。具体的命令类在继承该类的时候复写父类中的方法，从而实现了服务员通知烤肉者，而在Waiter类中声明一个私有命令类，和两个方法。当考虑到在点菜的过程中有的客户会取消或是更换菜品，所以近一步更改了Waiter类，并在该类中定一个了command数组，通过数组的add方法和Remove来进行对增加和减少订单。

职责链模式---权限问题解决

将对象连接成一个链，判断权限，直到有能处理的对象处理它。就是在定一个每个具体的处理类的时候首先是判断这个请求的权限，如果有权限则执行，如果没有权限则转到下一个高级别的。

中介者模式---联合国安理会要知道所有的国家

主要是依赖联合国安理会这个类，通过这个类来实现国家之间的通信，而不是各国之间直接通信，虽然实现了各个国家的独立，但是增加了安理会这个中介类的负担。

享元模式---通过判断来分享

通过网站工厂类来判断网站类的对象是否被实例化了，实例化则直接返回，没有实例化则实例化再返回。

解释器模式---解释

解释器固定，Context来传入，传入后判断。

访问者模式---状态和人类分开

把男人和女人成功和失败的状态分开，并且增加了对象结构类，来增加具体的男人类和女人类。性别稳定，状态稳定，人的个数可以增加，在状态中传递一个具体的人类来显示状态。

其实各个模式的本质是一致的，且模式就像算法？还是说是图纸上的框架呢？模式也不是绝对的，不同的需求适合不同的模式，找个平衡就好吧，还在在具体的盖房子过程中才会体会到吧。