设计模式博客

1. 如何学习JDK里的设计模式

最近在看JDK源码，想在毕业前再好好提高一下写代码的能力，JDK是个优秀的源码阅读范本（spring的源码也不错）。JDK目录下的src.zip里可以直接获得源码，我也push到了我Github的一个repo里。
网上搜了JDK设计模式，coolshell里也有一篇，不过我还是参照了Stackoverflow(原文链接)上的一个“Examples of GoF Design Patterns”的答复，详细列举了JDK里具体对应的类和函数，并结合了wiki上的许多整理好的优秀词条内容。放到这个博客上，也方便自己深入学习，好好体会下设计模式内涵，光看书也会很枯燥，况且纸质的代码看起来也不舒服。

2. 设计模式的相关图书

《设计模式：可复用面向对象软件的基础》
作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
出版社： 机械工业出版社副标题：可复用面向对象软件的基础译者：李英军、马晓星、蔡敏、刘建中出版年：2000-9页数：254定价：35.00元装帧：平装丛书：计算机科学丛书ISBN：9787111075752
《软件秘笈：设计模式那点事》

作者：郑阿奇
出版社：电子工业出版社
ISBN：9787121147821
出版时间：2011-11-01
丛书名：魅力·实践·发现
版次：1
页数：628
装帧：平装
所属分类：图书 > 计算机与互联网 > 软件工程及软件方法学
附件：CD光盘
定价：￥87.00
内容简介
本书在第1章软件设计模式概述后，从第2章到第24章诠释23个软件设计模式。每一种都以一个生活故事开始，然后是模式定义、模式分析、模式实现、设计原则和使用场合。模式实现通过Eclipse中的Java工程展开，采用软件编程诠释设计模式故事中的情节和操作，非常有趣。在这个基础上，总结该软件设计模式的设计原则，最后提出使用场合。第25章对各种软件设计模式进行系统总结，第26章是各种软件设计模式综合应用。
软道语录
设计模式
设计模式就是软件设计中对于特定问题的习惯的，通用的解决模式。
《设计模式：基于C#的工程化实现及扩展》
作者：王翔
出版社：电子工业出版社
出版时间：2009-1-1
字数：850000
版次：1
页数：652
开本：16开
印次：1
纸张：胶版纸
ISBN ：9787121075070
包装：平装
所属分类：图书 > 计算机/网络 > 程序设计 > C/C++/C#/VC/VC++
定价：￥98.00
专家推荐
本书立意明确，除了告诉你问题的类型与解法，还提供了可以立即演绎的程序代码，相信这本案头的工具书可以提供你一个不错的思维模式，帮你造就有弹性、能扩充、易维护的软件实体。
胡百敬微软MVP，台湾恒逸资讯资深讲师，“数据库铁人”
作者从GOF23种经典设计模式开始，带你走进模式的失门，小到细粒度的基础模式，大到粗粒度的架构模式，本书都做了详尽的讲解。如果您还在为了软件需求的无尽变化而烦恼不断，为了在软件设计领域更上一层楼而苦苦思索，希望本书能够带给您一些启发。
李会军微软MVP，博客园专家，IT168专栏作者
本书很有特色的地方，就是以工程角度来阐释模式，相较纯粹的模式之说，则更具普遍的下手角度，C#语言的高级特性结合设计模式的经典思想，两者相得益彰。
王涛微软MVP，博客园专家，《你必须知道的.NET》作者
内容简介
本书基于C# 2.0的语法，试图将GOF 23中的模式以一种可工程化的公共库而非Example的方式呈现给读者。内容包括以下7部分。
第1篇主要是概括性的介绍；第2篇创建型模式介绍通过将实例化职责委托他方对象的办法，隔离客户程序与具体类型实例化的依赖关系，保证客户程序（或者外部系统）获得期望具体类型实例的、同时不必发生直接的引用；第3篇结构型模式的重点在于如何通过灵活的体系组织不同的对象，并在此基础上完成更为复杂的类型（或者类型系统），而参与组合的各类型之间始终保持尽量松散的结构关系；第4篇行为型模式关注于应用运行过程中算法的提供和通信关系的梳理；第5篇主要介绍小颗粒度基础模式和应用案例；第6篇主要介绍应用全局的模式化的实现方法，包括现2009年已经被普遍应用的N层模式及某些关键性框架产品采用的“微内核”模式；第7篇主要是一些针对Web和Web Service领域的模式设计技术。
本书主要针对对C#语言和.NET Framework平台有一定了解或有一定应用经验的用户，尤其适于那些希望运用模式技术在设计和开发方面多应对些挑战的用户。
作者简介
王翔，软件架构师，主要从事.NET、XML、公钥基础设施的开发。专注于数据（尤其是XML信息）的生产、加工、交换、提炼等过程。2009年参与了一系列有关应用密码技术和PKI环境保护信息系统数据安全的项目。
最喜欢数学，平常案头总是摆一本数学练习题。闲暇时间喜欢写作，通过发表多种技术文章与国内外同行交流各种数据应用经验。
项目间隙经常到各海滨城市徒步旅行、野外露营、出海航行、极限运动，这几年烹饪也渐渐成为个人主要爱好。

3. zookeeper 用到哪些设计模式

ZooKeeper作为发现服务的问题

ZooKeeper(注：ZooKeeper是著名Hadoop的一个子项目，旨在解决大规模分
布式应用场景下，服务协调同步(Coordinate
Service)的问题;它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目，它
很成熟，有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用;但是用它来做Service发现服务解决方案则是个错误。

在分布式系统领域有个著名的 CAP定理(C-
数据一致性;A-服务可用性;P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个);ZooKeeper是个

CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注：也就

是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果)。但是别忘了，ZooKeeper是分布式协调服务，它的

职责是保证数据(注：配置数据，状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性

的了，如果是AP的，那么将会带来恐怖的后果(注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗?)。而且，
作为ZooKeeper的核心实现算法 Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。

作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了;因为对于Service发现服务来说就算
是
返回了包含不实的信息的结果也比什么都不返回要好;再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能
因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务是肯定错误的，如果你这么用就惨
了!

而且更何况，如果被用作Service发现服务，ZooKeeper本身并没有正确的处理网络分割的问题;而在云端，网络分割问题跟其他类型的
故障一样的确会发生;所以最好提前对这个问题做好100%的准备。就像 Jepsen在
ZooKeeper网站上发布的博客中所说：在ZooKeeper中，如果在同一个网络分区(partition)的节点数(nodes)数达不到
ZooKeeper选取Leader节点的逗法定人数地时，它们就会从ZooKeeper中断开，当然同时也就不能提供Service发现服务了。

如果给ZooKeeper加上客户端缓存(注：给ZooKeeper节点配上本地缓存)或者其他类似技术的话可以缓解ZooKeeper因为网
络故障造成节点同步信息错误的问题。 Pinterest与 Airbnb公
司就使用了这个方法来防止ZooKeeper故障发生。这种方式可以从表面上解决这个问题，具体地说，当部分或者所有节点跟ZooKeeper断开的情况
下，每个节点还可以从本地缓存中获取到数据;但是，即便如此，ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果
ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障(注：由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper

会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是逗健康地的，可以正常提供服务的;所以导致到达这些节点的服务请求
被丢失了。(注：这也是为什么ZooKeeper不满足CAP中A的原因)

更深层次的原因是，ZooKeeper是按照CP原则构建的，也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法
的
目的是为了让ZooKeeper变得更加可靠(available);但是，ZooKeeper设计的本意是保持节点的数据一致，也就是CP。所以，这样

一来，你可能既得不到一个数据一致的(CP)也得不到一个高可用的(AP)的Service发现服务了;因为，这相当于你在一个已有的CP系统上强制栓了
一个AP的系统，这在本质上就行不通的!一个Service发现服务应该从一开始就被设计成高可用的才行!

如果抛开CAP原理不管，正确的设置与维护ZooKeeper服务就非常的困难;错误会 经常发生，
导致很多工程被建立只是为了减轻维护ZooKeeper的难度。这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身。Knewton平台
很多故障就是由于ZooKeeper使用不当而导致的。那些看似简单的操作，如：正确的重建观察者(reestablishing
watcher)、客户端Session与异常的处理与在ZK窗口中管理内存都是非常容易导致ZooKeeper出错的。同时，我们确实也遇到过
ZooKeeper的一些经典bug： ZooKeeper-1159 与 ZooKeeper-1576;
我们甚至在生产环境中遇到过ZooKeeper选举Leader节点失败的情况。这些问题之所以会出现，在于ZooKeeper需要管理与保障所管辖服务
群的Session与网络连接资源(注：这些资源的管理在分布式系统环境下是极其困难的);但是它不负责管理服务的发现，所以使用ZooKeeper当
Service发现服务得不偿失。

做出正确的选择：Eureka的成功

我们把Service发现服务从ZooKeeper切换到了Eureka平台，它是一个开
源的服务发现解决方案，由Netflix公司开发。(注：Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作

服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。)Eureka一开
始就被设计成高可用与可伸缩的Service发现服务，这两个特点也是Netflix公司开发所有平台的两个特色。(
他们都在讨论Eureka)。自从切换工作开始到现在，我们实现了在生产环境中所有依赖于Eureka的产品没有下线维护的记录。我们也被告知过，在云平
台做服务迁移注定要遇到失败;但是我们从这个例子中得到的经验是，一个优秀的Service发现服务在其中发挥了至关重要的作用!

首先，在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切
换
到新的Eureka节点;当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中;而对于它来说，所有要做的无非是同步一些新的服务

注册信息而已。所以，再也不用担心有逗掉队地的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广

的网络分割故障，并实现逗0地宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务(注：ZooKeeper不会)：接收新
的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中(same side of
partition)，新发布的服务仍然可以被发现与访问。

但是，Eureka做到的不止这些。正常配置下，Eureka内置了心跳服务，用于淘汰一些逗濒死地的服务器;如果在Eureka中注册的服
务，
它的逗心跳地变得迟缓时，Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。这是个很好的功能，但是当网络分割故障发生时，

这也是非常危险的;因为，那些因为网络问题(注：心跳慢被剔除了)而被剔除出去的服务器本身是很地健康逗的，只是因为网络分割故障把Eureka集群分割
成了独立的子网而不能互访而已。

幸运的是，Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接(注：可能发生了网络故障)，那么这个
Eureka节点会进入地自我保护模式逗，同时保留那些逗心跳死亡逗的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对

于地死亡逗的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出地自我保护模式逗。所以Eureka的哲学是，同时保
留地好数据逗与地坏数据逗总比丢掉任何地好数据逗要更好，所以这种模式在实践中非常有效。

最后，Eureka还有客户端缓存功能(注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接
口)。
所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过

Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解
决这种问题时;得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。

Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，
这
样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心
跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源
的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。

维护Eureka服务器也非常的简单，比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。Eureka提供了一
个
web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka甚至提供
了Restful-API接口，方便第三方程序集成Eureka的功能。

4. C#的设计模式有哪些

C#设计模式（1）－Simple Factory Pattern
C#设计模式（2）－Factory Method Pattern
C#设计模式（3）－Abstract Factory Pattern
C#设计模式（4）－Singleton Pattern
C#设计模式（5）－Builder Pattern
C#设计模式（6）－Prototype Pattern
C#设计模式（7）－Adapter Pattern
C#设计模式（8）－Composite Pattern
C#设计模式（9）－Decorator Pattern
C#设计模式（10）－Proxy Pattern
设计模式（11）－Flyweight Pattern
设计模式（12）－Facade Pattern
设计模式（13）－Bridge Pattern
设计模式（14）－Chain of Responsibility Pattern
设计模式（15）－Command Pattern
设计模式（16）－Observer Pattern
设计模式（17）－Visitor Pattern
设计模式（18）－Template Method Pattern
设计模式（19）－Strategy Pattern

在博客园人搜索C#设计模式，会有详细的实践教程，这个更有效！
学海无涯啊！

5. 设计模式都有哪些

总体来说设计模式分为三大类：

一、创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

二、结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

三、行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

1、工厂方法模式：

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。

工厂模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，这就用到工厂方法模式。

创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。

2、抽象工厂模式：

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。抽象工厂需要创建一些列产品，着重点在于"创建哪些"产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。

3、单例模式：

单例对象（Singleton）是一种常用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。这样的模式有几个好处：

（1）某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。

（2）省去了new操作符，降低了系统内存的使用频率，减轻GC压力。

（3）有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。

4、建造者模式：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

5、原型模式：

原型模式虽然是创建型的模式，但是与工程模式没有关系，从名字即可看出，该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。本小结会通过对象的复制，进行讲解。在Java中，复制对象是通过clone()实现的，先创建一个原型类。

6、适配器模式：

适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。

7、装饰器模式：

顾名思义，装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。

8、代理模式：

代理模式就是多一个代理类出来，替原对象进行一些操作，比如我们在租房子的时候回去找中介，为什么呢？因为你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。

9、外观模式：

外观模式是为了解决类与类之家的依赖关系的，像spring一样，可以将类和类之间的关系配置到配置文件中，而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，该模式中没有涉及到接口。

10、桥接模式：

桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化。桥接的用意是：将抽象化与实现化解耦，使得二者可以独立变化，像我们常用的JDBC桥DriverManager一样。

JDBC进行连接数据库的时候，在各个数据库之间进行切换，基本不需要动太多的代码，甚至丝毫不用动，原因就是JDBC提供统一接口，每个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接就行了。

11、组合模式：

组合模式有时又叫部分-整体模式在处理类似树形结构的问题时比较方便。使用场景：将多个对象组合在一起进行操作，常用于表示树形结构中，例如二叉树，数等。

12、享元模式：

享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，通常与工厂模式一起使用。

13、策略模式：

策略模式定义了一系列算法，并将每个算法封装起来，使其可以相互替换，且算法的变化不会影响到使用算法的客户。需要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数。

14、模板方法模式：

一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。

15、观察者模式：

观察者模式很好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，如果后续有更新，会及时通知你。

其实，简单来讲就一句话：当一个对象变化时，其它依赖该对象的对象都会收到通知，并且随着变化！对象之间是一种一对多的关系。

16、迭代子模式：

顾名思义，迭代器模式就是顺序访问聚集中的对象，一般来说，集合中非常常见，如果对集合类比较熟悉的话，理解本模式会十分轻松。这句话包含两层意思：一是需要遍历的对象，即聚集对象，二是迭代器对象，用于对聚集对象进行遍历访问。

17、责任链模式：

责任链模式，有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。但是发出者并不清楚到底最终那个对象会处理该请求，所以，责任链模式可以实现，在隐瞒客户端的情况下，对系统进行动态的调整。

18、命令模式：

命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开。

19、备忘录模式：

主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，个人觉得叫备份模式更形象些，通俗的讲下：假设有原始类A，A中有各种属性，A可以决定需要备份的属性，备忘录类B是用来存储A的一些内部状态，类C呢，就是一个用来存储备忘录的，且只能存储，不能修改等操作。

20、状态模式：

状态模式在日常开发中用的挺多的，尤其是做网站的时候，我们有时希望根据对象的某一属性，区别开他们的一些功能，比如说简单的权限控制等。

21、访问者模式：

访问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。访问者模式适用于数据结构相对稳定算法又易变化的系统。因为访问者模式使得算法操作增加变得容易。

若系统数据结构对象易于变化，经常有新的数据对象增加进来，则不适合使用访问者模式。访问者模式的优点是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，其改变不影响系统数据结构。其缺点就是增加新的数据结构很困难。

22、中介者模式：

中介者模式也是用来降低类类之间的耦合的，因为如果类类之间有依赖关系的话，不利于功能的拓展和维护，因为只要修改一个对象，其它关联的对象都得进行修改。

如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行，这有点像spring容器的作用。

23、解释器模式：

解释器模式一般主要应用在OOP开发中的编译器的开发中，所以适用面比较窄。

(5)设计模式博客扩展阅读：

介绍三本关于设计模式的书：

1、《设计模式：可复用面向对象软件的基础》

作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

出版社： 机械工业出版社

2、《软件秘笈：设计模式那点事》

作者：郑阿奇

出版社：电子工业出版社

3、《设计模式：基于C#的工程化实现及扩展》

作者：王翔

出版社：电子工业出版社

6. 50分 .net架构师 必须要会全部的设计模式吗，还需要会什么

不一定啊，比较经典的几个要回，单例模式。工厂模式。观察者模式之类的，其实你只要有六七个模式能够熟练运用就已经足够了，有一本书写的挺好我之前在看，就叫设计模式，里面举例都是三国啊水浒啊一些故事来讲，挺逗的，涵盖了所有设计模式，基于java的，可以看一看，不用java也能有很多收获

7. 软件设计模式主要有哪几种

软件设计模式主要有以下三大类共23种：

一、创建型模式：

1、工厂方法模式工厂方法模式的创建是因为简单工厂模式有一个问题，在简单工厂模式中类的创建依赖工厂类，如果想要拓展程序，必须对工厂类进行修改，这违背了开闭原则，所以就出现了工厂方法模式，只需要创建一个工厂接口和多个工厂实现类。

2、抽象工厂模式抽象工厂模式是提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。区别于工厂方法模式的地方，工厂方法模式是创建一个工厂，可以实现多种对象；而抽象工厂模式是提供一个抽象工厂接口，里面定义多种工厂，每个工厂可以生产多种对象。

3、单例模式单例模式能保证一个类仅有一个实例，并提供一个访问它的全局访问点，同时在类内部创造单一对象，通过设置权限，使类外部无法再创造对象。单例对象能保证在一个JVM中，该对象只有一个实例存在。

4、建造者模式建造者模式是将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。在程序当中就是将一些不会变的基本组件，通过builder来进行组合，构建复杂对象，实现分离。

5、原型模式：原型模式是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。其实就是将对象复制了一份并返还给调用者，对象需继承Cloneable并重写clone方法。原型模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。

二、结构型模式：

1、适配器模式适配器模式是使得原本由于接口不兼容而不能一起工作的那些类可以一起工作，衔接两个不兼容、独立的接口的功能，使得它们能够一起工作，适配器起到中介的作用。

2、装饰模式：装饰器模式是动态地给一个对象添加一些额外的职责，给一个对象增加一些新的功能，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。除了动态的增加，也可以动态的撤销，要做到动态的形式，不可以用继承实现，因为继承是静态的。

3、代理模式代理模式是为其他对象提供一种代理以控制对这个对象的访问，也就是创建类的代理类，间接访问被代理类的过程中，对其功能加以控制。

4、外观模式外观模式是为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

5、桥接模式桥接模式是将抽象部分与实现部分分离，使它们都可以独立的变化。桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化（突然联想到了mvc模式）。

6、组合模式：组合模式是将对象组合成树形结构以表示"部分-整体"的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。

7、享元模式：享元模式是运用共享技术有效地支持大量细粒度的对象。享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，重用现有的同类对象，若未找到匹配的对象，则创建新对象，这样可以减少对象的创建，降低系统内存，提高效率。

三、行为型模式：

1、策略模式：

策略模式是定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换，且算法的变化不会影响到使用算法的客户。

2、模版方法模式：

模板方法模式是定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。该模式就是在一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。

模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤，将一些固定步骤、固定逻辑的方法封装成模板方法。调用模板方法即可完成那些特定的步骤。

3、观察者模式：

观察者模式是定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

也就是当被观察者状态变化时，通知所有观察者，这种依赖方式具有双向性，在QQ邮箱中的邮件订阅和RSS订阅，当用户浏览一些博客时，经常会看到RSS图标，简单来说就是当订阅了该文章，如果后续有更新，会及时通知用户。这种现象即是典型的观察者模式。

4、迭代器模式：

迭代器模式是提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。

在Java当中，将聚合类中遍历各个元素的行为分离出来，封装成迭代器，让迭代器来处理遍历的任务；使简化聚合类，同时又不暴露聚合类的内部，在我们经常使用的JDK中各个类也都是这些基本的东西。

5、责任链模式：

责任链模式是避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。

6、命令模式：

命令模式是将一个请求封装成一个对象，从而使发出者可以用不同的请求对客户进行参数化。模式当中存在调用者、接收者、命令三个对象，实现请求和执行分开；调用者选择命令发布，命令指定接收者。

7、备忘录模式：

备忘录模式是在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。创建一个备忘录类，用来存储原始类的信息；同时创建备忘录仓库类，用来存储备忘录类，主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，也就是做个备份。

8、状态模式：

状态模式是允许对象在内部状态发生改变时改变它的行为。对象具有多种状态，且每种状态具有特定的行为。

9、访问者模式：

访问者模式主要是将数据结构与数据操作分离。在被访问的类里面加一个对外提供接待访问者的接口，访问者封装了对被访问者结构的一些杂乱操作，解耦结构与算法，同时具有优秀的扩展性。通俗来讲就是一种分离对象数据结构与行为的方法。

10、中介者模式：

中介者模式是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

11、解释器模式：

解释器模式是给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子，基本也就用在这个范围内，适用面较窄，例如：正则表达式的解释等。

(7)设计模式博客扩展阅读：

软件设计的概念以及意义：

软件设计模式是对软件设计经验的总结，是对软件设计中反复出现的设计问题的成功解决方案的描述。为了记录这些成功的设计经验并方便以后使用，软件设计模式通常包含 4 个基本要素：模式名称、问题、解决方案以及效果。

模式名称实际上就是一个帮助记忆的名称，是用于软件设计的技术术语，有助于设计者之间的交流。

问题描述了设计者所面临的设计场景，用于告诉设计者在什么情况下使用该模式。

解决方案描述了设计的细节，通常会给出方案的原理图示（例如 UML 的类图，序列图等，也可能是一些示意图）及相关文字说明，如果可能，还会给出一些代码实例，以便对解决方案的深入理解。

效果描述了设计方案的优势和劣势，这些效果通常面向软件的质量属性，例如，可扩展性、可复用性等。

软件设计模式的重要意义在于设计复用。设计模式可以使设计者更加方便地借鉴或直接使用已经过证实的成功设计方案，而不必花费时间进行重复设计。一些设计模式甚至提供了显示的类图设计及代码实例，为设计的文档化及软件的开发提供了直接的支持。

8. 设计模式：适配器模式和代理模式的区别

这是之前我的博客总结的：

Proxy，代理模式：为其他对象提供一种代理以控制对这个对象的访问。
例如：经典的体现在Spring AOP切面中，Spring中利用了俩种代理类型。
其实，代理也分为静态和动态，但是我们一般常用动态，因为静态代理秀不起来

Adapter,适配器模式：将一类的接口转换成客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。
其中对象的适配器模式是各种结构型模式的起源，分为三种：类，对象，接口的适配器模式。

结一下三种适配器模式的应用场景：
类的适配器模式：当希望将一个类转换成满足另一个新接口的类时，可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。
对象的适配器模式：当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个Wrapper类，持有原类的一个实例，在Wrapper类的方法中，调用实例的方法就行。
接口的适配器模式：当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，实现所有方法，我们写别的类的时候，继承抽象类即可。

区别：很明显，适配器模式是因为新旧接口不一致导致出现了客户端无法得到满足的问题，但是，由于旧的接口是不能被完全重构掉的，因为我们还想使用实现了这个接口的一些服务。那么为了使用以前实现旧接口的服务，我们就应该把新的接口转换成旧接口。相比于适配器的应用场景，代理就不一样了，虽然代理也同样是增加了一层，但是，代理提供的接口和原本的接口是一样的，代理模式的作用是不把实现直接暴露给client，而是通过代理这个层，代理能够做一些处理。

9. Angularjs+SSH的设计模式是MVC还是属于MVVM

后端吐html，前端用Angular当然抄是可以的，我最近做的项目就是这样。

不要因为网上几篇博客，就认为Angular一定要被用来开发SPA，后端一定要吐JSON。后端吐HTML利于搜索引擎优化，前端用Angular写一个微型app处理些表单什么的不行吗？一定要把业务逻辑暴漏在js代码里，然后用户load页面要先下载好几百kb的script？在时间技术资源有限的情况下，一切的设计模式，架构，方法论，框架，库的选择和运用，到最终都是为了解决实际问题。

所以，你前端用MVVM模式，后端用MVC模式，整体上还是遵守了良好的系统架构，没有必要因为概念的限制来拘束你的系统设计。

10. Python有设计模式么

单例模式：Python 的单例模式最好不要借助类（在 Java 中借助类是因为 Java 所有代码都要写在类中），而是通过一个模块来实现。一个模块的模块内全局变量、模块内全局函数，组合起来就是一个单例对象了。
模板方法模式：这个可以像其他语言一样实现，但是如果要遵循鸭子类型原则的话，应该删除公有的抽象父类（或接口），从而追求灵活性。
工厂方法模式、多例模式：这个也不用借助类，直接写一个全局函数作为工厂函数即可。因为 Python 中实例化是通过 call 类来完成的，现在改成 call 工厂函数，对客户抠码者是透明的。（从这点我表示理解 Python 没有 new 操作符的好处了，使用通用的 call 定义，正交性极强）
装饰器模式、代理模式：这个接触过 Python 就不会不知道了，Python 内置的 decorator 语法如此著名。装饰器模式和代理模式都可以通过这种方式完成。另外一种是对对象的装饰或代理，这个也不需要按照契约编程的风格，让代理对象实现被代理对象的抽象。一切动态代理，只需要通过重载属性访问操作符，神马都简单了（和 PHP 通过 __get、__set、__call 来实现动态代理很类似）。
原型模式：这个在 Python 中实现的不是那么爽快，需要调用 来克隆原型对象。但是其实有另一种实现方式：之所以使用原型模式，是因为对象初始化需要较大开销。我们只需要保存初始化的结果，并在产生新对象的时候赋予新对象即可。所以，通过元类控制对象被创建的过程，来实现原型模式，也是一种选择。