Unified Modeling Language (UML)又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。面向对象的分析与设计(OOA&D，OOAD)方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。
本书主人公小菜(蔡遥)和大鸟(李大辽)
本书的模式
第一章简单工厂模式
1.1小菜(蔡遥)面试受挫
比如代码是否规范
class Program
{
static void Main(string[] args)
{
try
{
Console.WriteLine("请输入数字A:");
string strNumberA = Console.ReadLine();
Console.WriteLine("请选择运算符号:(+,-,*,/):");
string strOperate = Console.ReadLine();
Console.WriteLine("请输入数字B：");
string strNumberB = Console.ReadLine();
string strResult = "";
switch (strOperate)
{
case"+":
strResult = Convert.ToString(Convert.ToDouble(strNumberA) + Convert.ToDouble(strNumberB));
break;
case"-":
strResult = Convert.ToString(Convert.ToDouble(strNumberA) - Convert.ToDouble(strNumberB));
break;
case"*":
strResult = Convert.ToString(Convert.ToDouble(strNumberA) * Convert.ToDouble(strNumberB));
break;
case"/":
if (strNumberB != "0")
strResult = Convert.ToString(Convert.ToDouble(strNumberA) / Convert.ToDouble(strNumberB));
else
strResult = "除数不能为零";
break;
}
Console.WriteLine("结果为:" + strResult);
Console.ReadLine();
}
catch (Exception ex)
{
Console.WriteLine("您输入有误"+ex.Message);
}
}
}
使用面向对象代码容易维护，移植性好
第二章策略模式
根据条件实现功能
第三章单一职责原则(SRP)
就一个类而言，应该仅有一个引起变化的原因
比如手机功能多，集成多种设备为一身但是没有专业设备沉重，但是如果专业设备体积缩小了很多倍，功能并不消失，才是两全其美的办法
第四章开放-封闭原则
如香港和澳门的回归，实行一国两制方针，并不影响人民的生活
第五章依赖倒转原则
1.高层模块不应该依赖低层模块，两个都应该依赖抽象
2.抽象不应该细节，细节应该依赖抽象[ASD]
3.一个软件实体如果使用的是一个父类的话，那么一定要适用于其子类，而且它
察觉不出父类对象和子类对象的区别，也就是说，在软件里面，把父类都替换
成它的子类，程序行为没有变化。
4.里氏代换原则：子类行必须能够替换掉它们的父类型。
第六章装饰模式
1.把类中的装饰功能从类中搬移去除，这样可以简化原有的类。
2.有效的把类和核心职责和装饰功能分开了，而且还可以去除相关类中的重复的装
饰逻辑。
第七章代理模式
为其他对象提供一种代理以控制对这个对象的访问。
代理分为四种：
1.远程代理：也就是为一个对象在不同的地址空间提供局部代表，这样可以隐藏
一个对象存在于不同地址的事实[DP]
2.虚拟代理:根据需要创建的开销很大的对象，通过它存放实例化需要很长时间的
真是对象[DP]。
3.安全代理:用来控制真是对象访问的权限[DP]。
4.智能指引:调用真实对象时，代理处理另外一些事。
第八章工厂方法模式
1.简单工厂模式的最大优点就是工厂类中包含了必要的逻辑判断，根据客户端选
择条件多台实例化相关的类，对于客户端来说，去除了具体产品的依赖。
2.工厂方法模式：定义一个创建对象的接口，让子类决定实例化哪一个类，工厂
方法是一个类的实例化延迟到其子类。
第九章原型模式
1.用原型实例制定创建对象的种类，并且通过拷贝这些原型创建新的对象。
2.原型模式就是其实就是从一个对象再创建另外一个可定制的对象，而且不需要
知道任何创建的细节。
3.一般在初始化的信息不发生变化的情况下，克隆是最好的办法。这既隐藏了对
象创建的细节，有对性能大大的提高，而且好不用重新初始化对象，而是动态
的获得对象运行时的状态。
4.浅复制与深复制
MemberWiseClone()方法：如果字段是值类型的，则对该字段执行逐未复制，如
果字段是引用类型，则复制引用但不复制引用的对象；因此，原始对象及其复
本引用同一对象。
5.浅复制：被复制的对象所有变量都含有与原来对象相同的值，而所有的对其他
对象相同的值，而所有的对其他的对象的引用都仍然指向原来的对象。
6.深复制：把引用对象的变量指向复制过的新对象，而不是原有的被引用的对象。
第十章模板方法模式
1.既然用了继承，并且这个继承肯定有意义，就应该要成为子类的模板，所有重
复的代码都应该要上升到父类去，而不是让每个子类都去重复。
2.当我们要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在
详细的层次上的实现可能不同时。我们通常考虑用模板方法模式来处理。
3.模板方法模式：定义一个操作的算法的骨架，而将一些步骤延迟到子类中。模
板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
4.模板方法模式是通过把不变行为搬移到超类，去除子类的重复代码来体现它的
优势，还提供了一个很好的代码复用平台。
5.当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就
会在子类中重复出现。通过模板方法模式把这些行为搬移到单一的地方，这样
就帮助子类摆脱重复的不变行为的纠缠。
第十一章迪米特法则
1.如果连个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。
如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这
个调用。
2.在类的结构设计上，每一个类都应当尽量降低成员的访问权限
3.迪米特法则的根本思想，是强调了类之间的松耦合。类之间的耦合越弱，越利
于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及，信息的隐
藏促进了软件的复用。
第十二章外观模式
1.外观模式，为子系统的一组接口提供一个一致的界面，此模式定义了一个高层
接口，这个接口使得这一子系统更加容易使用。
何时使用外观模式：分为三个阶段来说
1.在设计初期阶段，应该要有意识的两个层分离，比如经典的三层架构。三层
体现了层与层之间建立外观。
2.在开发阶段，子系统往往因为不断的重构烟花而变得越来越复杂，增加外观
可以提供一个简单的接口，减少它们之间的依赖。
3.在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，
这时可以为新系统开发一个外观类，来提供粗糙或高度复杂的遗留代码的比
较清晰简单的接口，让新系统与外观对象交互，外观与遗留代码交互所有复
杂的工作。
第十三章建造者模式
1.将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的
表示的意图时，需要应用于建造者模式，如果用了建造者模式，那么用户就只
需指定需要建造的类型就可以找得到它们，而具体建造的过程和细节就不需知
道了。
2.建造者模式是在创建复杂对象的算法应该独立于该对象的组成部分以及它们的
装配方式适用的模式。
第十四章观察者模式
1.观察者定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题
对象。这个主题对象在状态发生变化是，会通知所有观察者的对象，使它们能
够自动更新自己。
2.观察者模式的特点：将一个系统分割成一系列相互协作的类有一个很不好的副
作用，那就是需要维护相关对象的移一致性。为了维持移植性使得个各类紧密
耦合，给维护带来不便。
观察者模式的使用方面：
1.当一个对象的改变需要同时改变其他对象的时候，而且还不知道具体有多少
的对象有待改变是，应该考虑使用观察者模式
2.一个抽象模型有两个方面，其中一个方面依赖于另一方面，这时用观察者模
式可以将这两着封装在独立对象中使它们各自独立地改变和复用
3.作用：解除耦合，让耦合的对方都依赖于具体，从而使得各自的变化都不会
影响另一边的变化。
4.委托用途：一个委托可以搭载多个方法，所有方法被依次唤起，更重要的是，
它可以使得委托对象搭载的方法并不需要属于同一个类。
5.委托对象仔仔的所有方法必须具有相同的原形和形式，也就是拥有相同的参
数列表和返回值类型。
第十五章抽象工厂模式
1.提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
2.优势：1.易于交换产品系列，只需改变具体工厂即可使用不同产品的配置。
2.让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操
作实例，产品的具体类名也被具体工厂的实现分离，不会出现在库户代
码中。
第十六章状态模式
1.当一个对象的内在状态改变是允许改变其行为，这个对象看起来像是改变了其
类。可以把复杂的判断逻辑简化
2.好处与用途消除庞大的条件分支语句，状态模式通过把各种状态转移逻辑分不
到State的子类之间，来减少相互间的依赖。
3.适用范围：当一个对象的行为取决于它的状态，并且必须在运行时刻根据状态
改变它的行为时，就可以考虑使用状态模式了。
第十七章适配器模式
1.将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接
口不兼容而不能一起工作的那个类可以一起工作。
2.系统的数据和行为都正确时，但接口不符时，应该考虑使用适配器，目的是使
控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复
用一些现存的类，但是接口又与复用环境要求不一致的情况。
3.适配器适用的场景：1.客户代码可以同一调用同一接口2.双方都不太容易修改的
时候再使用适配器模式适配。
第十八章备忘录模式
在不破坏封装性的前提下，捕获一个对象的内部连接，并在对象之外保存这个状态，这样以后就可将该对象恢复到原先保存的状态。
适用场景：
1.功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众
多属性中的一小部分
第十九章组合模式
1.将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个
对象和组合对象具有一致性。
2.透明方式，好处是枝节点和叶节点对于外界没有区别，它们具备完全一致的行为接
口。
3.何时使用：需求中是体现部分与整体层次的结构时，希望用户可以忽略组合对象与
单个对象的不同，同一地使用组合结构中的所有对象是，就应该考虑用组合模式了。
4.组合模式让客户可以一致地使用组合结构和单个对象。
第二十章迭代器模式
1.提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
2.需要对聚焦有躲在方式便利时，可以考虑用迭代器模式。
3.迭代器模式就是分离了集合对象的便利行为，抽象出一个迭代器类来负责，这样既
可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。
第二十一章单例模式
1.所有类都有构造的方法，不编码则系统默认生成空的构造方法，若有显示定义
的构造方法，默认的构造方法就会失效。
2.保证一个类仅有一个实例，并提供一个访问它的全局访问点。通常我们可以让
一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象。一个最
好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实
例可以被创建，并且它可以提供一个访问该实例的方法。
特点：受控访问
多线程时的单例：
Lock是确保当一个线程位于代码的临界区时，另一个线程不进入临界区。如果
其他线程视图进入锁定的代码，则它将一致等待，直到该对象被释放。
3.这种静态初始化的方式是在自己被加载时就将自己实例化，所以称之为恶汉式
加载，要在第一次被引用时，才会将自己实例化，所以被称之为懒汉式单例类。第二十二章桥接模式
1.对象关系继承的紧藕过于严密，限制了灵活性和复用性。
2.合成/聚合复用原则，尽量使用合成/聚成，尽量不要使用类继承。
3.桥接模式：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
第二十三章命令模式
概念：将一个请求封装为一个对象，从而使你可用不同的请求对象客户进行参数化；
对请求排队或记录请求日志，以及支持可撤销的操作。
命令模式的优点：(把请求一个操作的对象与知道怎么执行一个操作的对象分割开)
1.它能较容易地设计一个命令队列;
2.在需要的情况下，可以较容易地将命令记入日志；
3.允许接收请求的一方块决定是否要否决请求；
4.可以容易地实现对请求的撤销与重做；
5.增加新的具体命令很容易
第二十四章职责链模式
概念：是多个对象都有机会前处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递请求，知道有一个对象处理它为止。
优点：可以随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。第二十五章中介者模式
概念：用一个中介对象来封装一系列的对象交互。中介者使各对象要显示地相互引用，从而使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
优缺点：
缺点：当系统出现多对多的情况交互复杂的对象群时，很容易在系统中误用。
优点：减少了各个之间的耦合，使得可以独立的改变和复用。
第二十六章享元模式
概念：运用共享技术有效地支持大量细粒度的对象。
优点：享元模式可以避免大量非常相似类的开销。如果能把那些参数移到类实例的外面，在方法调用是将它们传递过来，就可以通过功效大幅度地减少单个实例的数目。
第二十七章解释器模式
概念：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释使用该表示来解释语言中的句子。
优缺点：
1.优点：易于直接编写。
2.缺点：文法可能难以管理和维护
第二十八章访问者模式
概念：表示一个作用于某个对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
适用范围：数据结构相对稳定的系统。
创建型结构型行为型 类Factory Method Adapter In terpreter Template Method 对象 Abstract Factory Builder Prototype Si ngleto n Apapter(对象) Bridge Composite Decorator Fa?ade Flyweight Proxy Chain of Resp on sibility Comma nd Iterator Mediator Meme nto Observer State Strategy Visitor （抽象工厂） 提供一个创建一系列相关或互相依赖对象的接口，而无须制定它们具体的类。 图10-25抽象工厂模式结构图 Abstract Factory 抽象工厂 class Program { static void Main(string[] args) { AbstractFactory factory1 = new Con creteFactory1(); Clie nt c1 = new Clie nt(factory1); c1.Ru n(); AbstractFactory factory2 = new Con creteFactory2(); Clie nt c2 = new Clie nt(factory2); c2.Ru n(); Co nsole.Read(); abstract class AbstractFactory { public abstract AbstractProductA CreateProductA(); public abstract AbstractProductB
23种设计模式趣味讲解 对设计模式很有意思的诠释，呵呵，原作者不详。 创立型模式 1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，固然口味有所不同，但不管你带MM往麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类离开。花费者任何时候需要某种产品，只需向工厂恳求即可。花费者无须修正就可以接纳新产品。毛病是当产品修正时，工厂类也要做相应的修正。如：如何创立及如何向客户端供给。 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同处所的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM 我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这必定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的天生过程分割开来，从而使一个建造过程天生具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变更，客户不必知道产品内部组成的细节。建造模式可以强迫履行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM往麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。 工厂方法模式：核心工厂类不再负责所有产品的创立，而是将具体创立的工作交给子类往做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的串口，而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天，必定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要） 原始模型模式：通过给出一个原型对象来指明所要创立的对象的类型，然后用复制这个原型对象的方法创立出更多同类型的对象。原始模型模式容许动态的增加或减少产品类，产品类不需要非得有任何事先断定的等级结构，原始模型模式实用于任何的等级结构。毛病是每一个类都必须配备一个克隆方法。 5、SINGLETON—俺有6个美丽的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，
Spring作为现在最优秀的框架之一，已被广泛的使用，51CTO也曾经针对Spring框架中的JDBC应用做过报道。本文将从另外一个视角试图剖析出Spring框架的作者设计Spring框架的骨骼架构的设计理念。 Rod Johson在2002年编著的《Expert one to one J2EE design and development》一书中，对Java EE正统框架臃肿、低效、脱离现实的种种现状提出了质疑，并积极寻求探索革新之道。以此书为指导思想，他编写了interface21框架，这是一个力图冲破Java EE传统开发的困境，从实际需求出发，着眼于轻便、灵巧，易于开发、测试和部署的轻量级开发框架。Spring框架即以interface21框架为基础，经过重新设计，并不断丰富其内涵，于2004年3月24日，发布了1.0正式版。同年他又推出了一部堪称经典的力作《Expert one-to-one J2EE Development without EJB》，该书在Java世界掀起了轩然大波，不断改变着Java开发者程序设计和开发的思考方式。在该书中，作者根据自己多年丰富的实践经验，对EJB 的各种笨重臃肿的结构进行了逐一的分析和否定，并分别以简洁实用的方式替换之。至此一战功成，Rod Johnson 成为一个改变Java世界的大师级人物。 传统J2EE应用的开发效率低，应用服务器厂商对各种技术的支持并没有真正统一，导致J2EE的应用没有真正实现Write Once及Run Anywhere的承诺。Spring作为开源的中间件，独立于各种应用服务器，甚至无须应用服务器的支持，也能提供应用服务器的功能，如声明式事务等。 Spring致力于J2EE应用的各层的解决方案，而不是仅仅专注于某一层的方案。可以说Spring是企业应用开发的“一站式”选择，并贯穿表现层、业务层及持久层。然而，Spring并不想取代那些已有的框架，而与它们无缝地整合。 Spring简介 Spring是一个开源框架，它由Rod Johnson创建。它是为了解决企业应用开发的复杂性而创建的。Spring 使用基本的JavaBean来完成以前只可能由EJB完成的事情。然而，Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度而言，任何Java应用都可以从Spring中受益。 ◆目的：解决企业应用开发的复杂性 ◆功能：使用基本的JavaBean代替EJB，并提供了更多的企业应用功能 ◆范围：任何Java应用 简单来说，Spring是一个轻量级的控制反转(IoC)和面向切面(AOP)的容器框架。 ◆轻量——从大小与开销两方面而言Spring都是轻量的。完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布。并且 Spring所需的处理开销也是微不足道的。此外，Spring是非侵入式的：典型地，Spring应用中的对象不依赖于Spring的特定类。 ◆控制反转——Spring通过一种称作控制反转（IoC）的技术促进了松耦合。当应用了IoC，一个对象依赖的其它对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。你可以认为IoC与JNDI相反——不是对象从容器中查找依赖，而是容器在对象初始化时不等对象请求就主动将依赖传递给它。 ◆面向切面——Spring提供了面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统级服务（例如审计（auditing）和事务（）管理）进行内聚性的开发。应用对象只实现它们应该做的——完成业务逻辑——仅此而已。它们并不负责（甚至是意识）其它的系统级关注点，例如日志或事务支持。 ◆容器——Spring包含并管理应用对象的配置和生命周期，在这个意义上它是一种容器，你可以配置你的每个bean如何被创建——基于一个可配置原型（prototype），你的bean可以创建一个单独的实例或者每次需要时都生成一个新的实例——以及它们是如何相互关联的。然而，Spring不应该被混同于传统的重量级的EJB容器，它们经常是庞大与笨重的，难以使用。 ◆框架——Spring可以将简单的组件配置、组合成为复杂的应用。在Spring中，应用对象被声明式地组合，典型地是在一个XML文件里。Spring也提供了很多基础功能（事务管理、持久化框架集成等等），将
你想修改按钮，窗体，列表框，而不是其代码的时候,比方说，把按钮拉大，如果用普通模式，很可能不小心变成点击运行了，用设计模式，点击就是修改按钮。 在需要“设计模式”下干的活需要用到“设计模式”~~~~~~~~在“普通模式”下不能做的事不能在“普通模式”下做，只有在“设计模式”下的做的事只能在“设计模式”下做。 设计模式下禁用所有宏，此时只能执行设计窗体、编写代码，退出设计模式后可以执行代码。 在设计模式下，鼠标放在代码中，再点调试工具栏上的执行按钮，宏被执行了。 如何禁用设计模式 Private Sub Workbook_Open() Macro1 End Sub Macro1放在模組裡。 Sub Macro1() Dim cbar As CommandBar For Each cbar In CommandBars With cbar For i = 1 To .Controls.Count If .Controls(i).ID = 1605 And .Controls(i).Enabled = True Then .Controls(i).Enabled = False End If Next i End With N ext End Sub Sub x() Dim ctrl As CommandBarControl For Each ctrl In CommandBars.FindControls(Type:=msoControlButton, ID:=1605) ctrl.Enabled = False Next ctrl End Sub
Private Sub Workbook_Open() https://www.doczj.com/doc/758785944.html,mandBars("Visual Basic").Controls(6).Enabled = False https://www.doczj.com/doc/758785944.html,mandBars("Control Toolbox").Controls(1).Enabled = False End Sub
Gof的23种设计模式 从2005年初听说设计模式，到现在虽然已经8年多了，但GoF的23种模式依然盛行，当然GoF提出这些模式的 年代更加久远（1995年）。在工作的过程中，陆陆续续接触了GoF的大部分模式，我记得在2008年的时候就想总结一下设计模式（最近想做的两件事情），最后因为各种原 因也没有完成。最近这段时间正好是职业空档期，没什么事儿做，就把之前看过的设计模式翻出来整理了一下，于是就有了上面几篇文章。整理设计模式的过程，也是一个深刻理解面向对象设计的过程。通过对各个模式的回顾，让我更能够明白前辈们关于面向对象设计提出的各种“最佳实践”，特别是S.O.L.I.D，我觉得在这里再说一次，也不算矫情。S：单一职责原则（Single Responsibility Principle, SRP），一个类只能有一个原因使其发生改变，即一个类只承担一个职责。 O：开放-封闭原则（Open-Close Principle, OCP），这里指我们的设计应该针对扩展开放，针对修改关闭，即尽量以扩展的方式来维护系统。 L：里氏替换原则（Liskov Subsititution Principle, LSP），它表示我们可以在代码中使用任意子类来替代父类并且程 序不受影响，这样可以保证我们使用“继承”并没有破坏父类。
I：接口隔离原则（Interface Segregation Principle, ISP），客户端不应该依赖于它不需要的接口，两个类之间的依赖应该建立在最小接口的基础上。这条原则的目的是为了让那些使用相同接口的类只需要实现特定必要的一组方法，而不是大量没用的方法。 D：依赖倒置原则（Dependence Inversion Principle, DIP），高层模块不应该依赖于低层模块，两者应该都依赖于抽象；抽象不依赖于细节，而细节应该依赖于抽象。这里主要是提倡“面向接口”编程，而非“面向实现”编程。设计模式，从本质上讲，是针对过去某种经验的总结。每种设计模式，都是为了在特定条件下去解决特定问题，离开这些前提去讨论设计模式，是没有意义的。下面，我们快速回顾GoF的23种模式。工厂方法 意图：定义一个用户创建对象的接口，让子类去决定具体使用哪个类。 适用场合：1）类不知道它所要创建的对象的类信息；2）类希望由它的子类来创建对象。抽象工厂 意图：提供一个创建一系列相关或者相互依赖的对象的接口，而无须指定它的具体实现类。 适用场合：1）系统不依赖于产品是如何实现的细节；2）系统的产品族大于1，而在运行时刻只需要某一种产品族；3）属于同一个产品族的产品，必须绑在一起使用；4）所有的
《JAVA设计模式》复习资料 一、单项选择题 1．设计模式起源于（） A、机械设计 B、建筑工程设计 C、水利工程设计 D、工业电力化设计 2．“不要和陌生人说话”是（）原则的通俗表述。 A、接口隔离 B、里氏替换 C、依赖倒置 D、迪米特 3．目前常见的设计模式主要有（）种。 A、23 B、21 C、32 D、28 4．以下关于单一职责原则的叙述不正确的是（）。 A、单一职责原则的英文名称是Single Responsibility Principle. B、单一职责原则要求一个类只有一个职责 C、单一职责原则有利于对象的稳定，降低类的复杂性 D、单一职责原则提高了类之间的耦合性 5．以下关于依赖倒置原则的叙述不正确的是（） A、依赖倒置原则的简称是DIP B、高层模块不依赖于低层模块，低层模块依赖于高层模块 C、依赖倒置原则中高层模块和低层模块都依赖于抽象 D、依赖倒置原则实现模块间的松耦合 6．下面关于单例模式说法错误的是（） A、单例模式是指一个类只有一个实例 B、单例类从实现方式上分为懒汉式和饿汉式 C、单例类从功能上分为状态单例类和无状态单例类 D、可以通过继承的方式对单例类进行扩展得到功能更丰富的单例类 7．下面关于工厂方法模式说法错误的是（）。 A、工厂方法模式使一个类是实例化延迟到其子类中 B、工厂方法模式中具有抽象工厂、具体工厂、抽象产品和具体产品4个角色 C、工厂方法模式可以处理多个产品的多个等级结构 D、工厂方法模式可以屏蔽产品类 8．在以下情况不适合使用责任职责链模式（） A、有多个对象可以处理请求，哪个对象处理该请求在运行时刻自动确定。 B、在需要用比较通用和复杂的对象指针代替简单的指针的时候。 C、你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 D、一个请求需要一系列的处理工作。 9．当我们想创建一个具体的对象而又不希望指定具体的类时，可以使用（）模式 A、结构型 B、创建型 C、行为型 D、以上都可以 10．以下用来描述适配器模式的是（） A、表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。 B、定义一个用于创建对象的接口，让子类决定实例化哪一个类。
总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 1、开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。 2、里氏代换原则（Liskov Substitution Principle） 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则（Dependence Inversion Principle） 这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。 4、接口隔离原则（Interface Segregation Principle） 这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。 5、迪米特法则（最少知道原则）（Demeter Principle） 为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。 6、合成复用原则（Composite Reuse Principle） 原则是尽量使用合成/聚合的方式，而不是使用继承。 三、Java的23中设计模式 从这一块开始，我们详细介绍Java中23种设计模式的概念，应用场景等情况，并结合他们的特点及设计模式的原则进行分析。 1、工厂方法模式（Factory Method） 工厂方法模式分为三种：
二十三种设计模式类图 0 引言 谈到设计模式，绝对应该一起来说说重构。重构给我们带来了什么？除了作为对遗留代码的改进的方法，另一大意义在于，可以让我们在写程序的时候可以不需事先考虑太多的代码组织问题，当然这其中也包括了应用模式的问题。尽管大多数开发者都已经养成了写代码前先从设计开始的习惯，但是，这种程度的设计，涉及到到大局、到总体架构、到主要的模块划分我觉得就够了。换句话说，这时就能写代码了。这就得益于重构的思想了。如果没有重构的思想，有希望获得非常高质量的代码，我们就不得不在开始写代码前考虑更多其实并非非常稳定的代码组织及设计模式的应用问题，那开发效率当然就大打折扣了。在重构和设计模式的合理应用之下，我们可以相对较早的开始写代码，并在功能尽早实现的同时，不断地通过重构和模式来改善我们的代码质量。所以，下面的章节中，在谈模式的同时，我也会谈谈关于常用的这些模式的重构成本的理解。重构成本越高意味着，在遇到类似的问题情形的时候，我们更应该提前考虑应用对应的设计模式，而重构成本比较低则说明，类似的情形下，完全可以先怎么方便，怎么快怎么写，哪怕代码不是很优雅也没关系，回头再重构也很容易。 1 创建型 1.1FactoryMethod 思想：Factory Method的主要思想是使一个类的实例化延迟到其子类。 场景：典型的应用场景如：在某个系统开发的较早阶段，有某些类的实例化过程，实例化方式可能还不是很确定，或者实际实例化的对象（可能是需要对象的某个子类中的一个）不确定，或者比较容易变化。此时，如果直接将实例化过程写在某个函数中，那么一般就是if-else或select-case代码。如果，候选项的数目较少、类型基本确定，那么这样的if-else 还是可以接受的，一旦情形变得复杂、不确定性增加，更甚至包含这个构造过程的函数所
【关键字】模式 一、设计模式的分类 总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 总原则：开闭原则（Open Close Principle） 开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。 1、单一职责原则 不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。 2、里氏替换原则（Liskov Substitution Principle） 里氏代换原则(Liskov Substitution Principle LSP)面向东西设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 历史替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。 3、依赖倒转原则（Dependence Inversion Principle） 这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。 4、接口隔离原则（Interface Segregation Principle） 这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。 5、迪米特法则（最少知道原则）（Demeter Principle）
Bean的定义主要有BeanDefinition描述，如下图说明了这些类的层次关系： 图5.Bean定义的类层次关系图 Bean的定义就是完整的描述了在Spring的配置文件中你定义的节点中所有的信息，包括各种子节点。当Spring成功解析你定义的一个节点后，在Spring的内部他就被转化成BeanDefinition对象。以后所有的操作都是对这个对象完成的。 Bean的解析过程非常复杂，功能被分的很细，因为这里需要被扩展的地方很多，必须保证有足够的灵活性，以应对可能的变化。Bean的解析主要就是对Spring配置文件的解析。这个解析过程主要通过下图中的类完成： 图6.Bean的解析类
当然还有具体对tag的解析这里并没有列出。 Context组件 Context在Spring的org.springframework.context包下，前面已经讲解了Context组件在Spring中的作用，他实际上就是给Spring提供一个运行时的环境，用以保存各个对象的状态。下面看一下这个环境是如何构建的。 ApplicationContext是Context的顶级父类，他除了能标识一个应用环境的基本信息外，他还继承了五个接口，这五个接口主要是扩展了Context的功能。下面是Context的类结构图： 图7.Context相关的类结构图 从上图中可以看出ApplicationContext继承了BeanFactory，这也说明了Spring容器中运行的主体对象是Bean，另外ApplicationContext继承了ResourceLoader接口，使得ApplicationContext可以访问到任何外部资源，这将在Core中详细说明。 ApplicationContext的子类主要包含两个方面： ConfigurableApplicationContext表示该Context是可修改的，也就是在构建Context中用户可以动态添加或修改已有的配置信息，它下面又有多个子类，其中最经常使用的是可更新的Context，即AbstractRefreshableApplicationContext类。 WebApplicationContext顾名思义，就是为web准备的Context他可以直接访问到ServletContext，通常情况下，这个接口使用的少。
设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。设计模式分类：创建型、结构型、行为型。 创建型模式功能：1.统所使用的具体类的信息封装起来； 2.类的实例是如何被创建和组织的。 创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。 2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。 常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。 常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。单一职责原则：一个类应该只有一个职责。 优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。 里氏替换原则： 优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。 缺点：1.继承是入侵式的。只要继承，就必须拥有父类所有属性和方法。 2.降低代码的灵活性。子类必须拥有父类的属性和方法，使子类收到限制。 3.增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种 修改可能造成大片的代码需要重构。 依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。 在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类； 实现类依赖于接口或抽象类。 接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的 2.一个接口代表一个角色，不应当将不同的角色交给一个接口。 3.不应该强迫客户使用它们的不同方法。 如图所示的电子商务系统在三个地方会使用到订单类：一个是门户，只能有查询方法；一个是外部系统，有添加订单的方法；一个是管理后台，添加、删除、修改、查询都要用到。“原子”在实践中的衡量规则： 1.一个接口只对一个子模块或者业务逻辑进行分类。 2.只保留接口中业务逻辑需要的public方法。 3.尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理。 4.接口设计应因项目而异，因环境而异，不能照搬教条。 迪米特法则：（表述）只与你直接的朋友们通信；不要跟“陌生人”说话；每一个软件单位 对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密 切相关的软件单位。 对迪米特法则进行模式设计有两个：外观模式、中介者模式。 开闭原则：一个软件实体应当对扩展开放，对修改关闭。 重要性体现：提高复用性；提高维护性；提高灵活性；易于测试
23种设计模式UML 类图及对应示例代码(一) 收藏 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 using System; namespace DoFactory.GangOfFour.Abstract.Structural { ///
class MainApp { ///
关于23种设计模式新解 创建型模式 1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你” builder。（这一定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的
细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的 MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。 工厂方法模式：核心工厂类不再负责所有产品的创建，而是将 具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给 出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例 化这种细节。 4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里 面就行了，这就是我的情话prototype了。（100块钱一份，你要 不要） 原始模型模式：通过给出一个原型对象来指明所要创建的对象 的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有 任何事先确定的等级结构，原始模型模式适用于任何的等级结构。 缺点是每一个类都必须配备一个克隆方法。 5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，
c,,,设计模式,面试 篇一：八设计模式java面试题 八、设计模式基础知识 1、设计模式及框架定义和作用？ 设计模式：设计模式是一种问题的解决思路，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，它已经适用于一个实践环境，并且可以适用于其它环境。 使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性，为设计提供共同的词汇，可以节省大量时间，使代码编制真正工程化 框架：框架是构成一类特定软件可复用设计的一组相互协作的类，框架通常定义了应用体系的整体结构类和对象的关系等等设计参数。 框架便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策，框架强调设计复用，因此框架设计中必然要使用设计模式，设计模式有助于对框架结构的理解，成熟的框架通常使用了多种设计模式
2、开发中都用到了哪些设计模式？(J2EE常用的设计模式？)用在什么场合？ 答：singleton:单例,用来减少垃圾对象和缓存用 factory:工厂模式,用来解耦(其实模式都用来解耦的)facade和decorator:封装接口 command:命令模式，传递 Iterator:用来遍历对象Observer:用来监听状态变化(现在习惯用listener机制替代) templete:模板模式，用来处理相同的操作步骤strategy:策略模式，策略选择 proxy:用来附加功能，属性或隐蔽。 bridge也很实用，用来解耦工厂与产品搭配之类的选择服务定位者模式，前端控制器模式，DAO模式，代理模式，装饰者模式等注：MVC模式准确来说并不是设计模式，而是架构。详解如下： MVC模式是一个复杂的架构模式，其实现也显得非常复杂。但是，我们已经总结出了很多可靠的设计模式，多种设计模式结合在一起，使MVC模式的实现变得相对简单易行。Views可以看作一棵树，显然可以用Composite Pattern(合成模式)来实现。Views和Models之间的关系可以用Observer Pattern(观察者模式)体现。Controller控制
1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM 爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory。工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM 到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好
八种架构设计模式及其优缺点概述(上) 1. 什么是架构 我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。哈哈，我理解，架构就是骨架，如下图所示： 人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。架构对于软件的重要性不亚于骨架对人类身体的重要性。 2. 什么是设计模式
这个问题我问过的面试者不下于数十次，回答五花八门，在我看来，模式就是经验，设计模式就是设计经验，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计，这样可以大大节省我们的设计时间，提高工作效率。 作为一个工作10年以上的老码农，经历的系统架构设计也算不少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。总体而言，共有八种，分别是： 1.单库单应用模式：最简单的，可能大家都见过 2.内容分发模式：目前用的比较多 3.查询分离模式：对于大并发的查询、业务 4.微服务模式：适用于复杂的业务模式的拆解 5.多级缓存模式：可以把缓存玩的很好 6.分库分表模式：解决单机数据库瓶颈 7.弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一 8.多机房模式：解决高可用、高性能的一种方法 3. 单库单应用模式这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图：
如上图所示，这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统，所有的业务都是用过业务层完成的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。虽然简单，但是也并不是一无是处。
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。 缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。 4. 内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式，常见的应用场景是使用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器。这种模式的一般设计见下图：
工厂模式在《Java与模式》中分为三类： 1）简单工厂模式（Simple Factory）：不利于产生系列产品； 2）工厂方法模式（Factory Method）：又称为多形性工厂； 3）抽象工厂模式（Abstract Factory）：又称为工具箱，产生产品族，但不利于产生新的产品； 这三种模式从上到下逐步抽象，并且更具一般性。 GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Metho d）与抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。 二、简单工厂模式 简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。 在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。 先来看看它的组成： 1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。 2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽象类来实现。 3) 具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。 三、工厂方法模式 工厂方法模式是简单工厂模式的进一步抽象化和推广，工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给抽象工厂的子类去做。 来看下它的组成： 1)抽象工厂角色：这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。 3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类
浅析23种软件设计模式 1、工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 4、原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。 5、单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 6、适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。 7、桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。 8、合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。 9、装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。 10、门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。 11、享元模式：FL YWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存