dragon_fire的专栏

简单工厂模式解释：        简单工厂模式（Simple Factory Pattern）属于类的创新型模式，又叫静态工厂方法模式（Static FactoryMethod Pattern）,是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。简单工厂模式的UML图：        简单工厂模式中包含的角色及其相应的职责如下：

在学习面向对象设计对象关系时，依赖、关联、聚合和组合这四种关系之间区别比较容易混淆。特别是后三种，仅仅是在语义上有所区别，所谓语义就是指上下文环境、特定情景等。他们在编程语言中的体现却是基本相同的，但是基本相同并不等于完全相同，这一点在我的前一篇博文《设计模式中类的关系》中已经有所提及，下面就来详细的论述一下在java中如何准确的体现依赖、关联、聚合和组合。首先看一看书上对这四种关系的定义

定义：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。类型：行为类模式类图：        首先来看一段代码：[java] view plaincopypublic void test(int i, Request req

定义：定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。类型：行为类模式类图：        在软件系统中经常会有这样的需求：如果一个对象的状态发生改变，某些与它相关的对象也要随之做出相应的变化。比如，我们要设计一个右键菜单的功能，只要在软件的有效区域内点击鼠标右键，就会弹出一个菜单；再比如，我们要设计一个自动部署

定义：提供一种方法访问一个容器对象中各个元素，而又不暴露该对象的内部细节。类型：行为类模式类图：       如果要问java中使用最多的一种模式，答案不是单例模式，也不是工厂模式，更不是策略模式，而是迭代器模式，先来看一段代码吧：[java] view plaincopypublic static void prin

定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。类型：行为类模式类图：命令模式的结构        顾名思义，命令模式就是对命令的封装，首先来看一下命令模式类图中的基本结构：Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute

享元模式(Flyweight)就是把部分和整体的关系用树形结构来表示，从而使客户端能够把一个个的部分对象和有他们组合起来的整体对象采用同样的方式看待，他也是一个继承的替代，其实具体的说，享元模式就是用时间交换了空间。用程序的运行速度来读取是否重复的对象内容，然后不创建一个重复的对象来节省空间，于此同时就大大提高了程序的运行效率。下面就简单的原理图：然后通过一个字符的库创

Java动态代理模式 1. 代理:一个角色代表别一个角色来完成某些特定的功能。 比如：生产商，中间商，客户这三者这间的关系 客户买产品并不直接与生产商打交道，也不用知道产品是如何产生的，客户只与中间商打交道，而中间商就可以对产品进行一些包装，提供一些售后的服务。 代理模式有三个角色: 1. 抽象主题角色 2. 代理主题角色 3. 实际被代理角色 其它类通过访问代理主题角色来

1. 适配器模式简介     适配器模式（Adapter）：将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。     适用场景：     1、已经存在的类的接口不符合我们的需求；     2、创建一个可以复用的类，使得该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作；

Java与模式：缺省适配器模式 上文谈到了适配器模式，要是Targer目标角色有20方法，那么每个适配器都要去实现接口中这些方法，这样做感觉太费劲。 这种情况下，可以考虑实现个默认适配器，然后实际的实现目标角色接口的类可以集成这个默认适配器，然后重写默认实现的方法即可。 一、原理图 二、例子 下面以一个简单例子

合成（Composite）模式是一种非常重要的设计模式，合成模式将对象组织到树中，用来描述树的关系。 一、原理图 从原理图可见，File、Folder都可以同等看待苇IFile，为对象管理提供了极大的便利。当然，树的概念不单单是文件文件夹的层次概念，只是因为这个很形象，实际中还有很多树的概念，比如组织机构，分类层次等等，都是逻辑上的概念，不管是物理上

Java装饰模式 装饰模式：给一个类添加一些额外的职责，并且在添加这些额外的职责时不会控制该类的执行逻辑。 UML类图：  组成部分： 抽象构件：原始的功能接口 具体构件：具体的原始功能类 装饰角色：持有具体构件类的对象，以便执行原有功能 具体装饰：具体扩展的功能在这里 下面看一个对开车功能拓展的实例（晚上+开车）： 抽象构件： Ja

简介亨元模式(Flyweight Pattern)可以理解成为轻量级模式,是一种软件设计模式。  亨元模式结构图面向对象的思想很好地解决了抽象性的问题，一般也不会出现性能上的问题。但是在某些情况下，对象的数量可能会太多，从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象，同时又不影响客户程序使用面向对象的方式进行操作。图1　Flyweight

[摘要]门面模式要求一个子系统的外部与其内部的通信必须通过一个统一的门面对(Facade)象进行，本文介绍Java设计模式 之门面模式(Facade)门面模式要求一个子系统的外部与其内部的通信必须通过一个统一的门面对(Facade)象进行。迪米特法则：只与你直接的朋友们通信。此设计模式需要一个设计不是很好的系统进行改造来进行对比Facade倒底做些什么。以下为一

在java以及其他的面向对象设计模式中，类与类之间主要有6种关系，他们分别是：依赖、关联、聚合、组合、继承、实现。他们的耦合度依次增强。1. 依赖（Dependence）         依赖关系的定义为：对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。定义比较晦涩难懂，但在java中的表现还是比较直

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。         开闭原则是面

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T

工厂方法模式工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。你应该大致猜出了工厂方法模式的结构，来看下它的组成：1) 抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java 中它由抽象类或者接口来实现。

工厂方法模式（Factory Method）——.NET设计模式系列之五Terrylee，2004年1月2日概述在软件系统中，经常面临着“某个对象”的创建工作，由于需求的变化，这个对象的具体实现经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化？提供一种封装机制来隔离出“这个易变对象”的变化，从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变？这就是要说的

简单工厂：严格说并不是一个设计模式。简单工厂没有抽象类，只有一个具体工厂类如MyFactory，然后MyFactory里面有个工厂方法CreateProduct返回一个基类产品，具体返回什么具体实例通过传入参数然后用case判断。用手机生产做个例子：比如Nokia简单工厂就是只有NokiaFactory工厂类，工厂方法就是CreateNokiaPhone，参数是Nokia手机型号，

定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。类型：创建类模式类图：四个要素产品类：一般是一个较为复杂的对象，也就是说创建对象的过程比较复杂，一般会有比较多的代码量。在本类图中，产品类是一个具体的类，而非抽象类。实际编程中，产品类可以是由一个抽象类与它的不同实现组成，也可以是由多个抽象类与他们的实现组成。抽象建造者：引入抽象

以下是我再次研究单例（java 单例模式缺点）时在网上收集的资料，相信你们看完就对单例完全掌握了Java单例模式应该是看起来以及用起来简单的一种设计模式，但是就实现方式以及原理来说，也并不浅显哦。 总结一下我所知道的单例模式实现方式： 1.预先加载法 Java代码 class S1 {       privat

Jvm的垃圾回收机制到底会不会回收掉长时间不用的单例模式对象，这的确是一个比较有争议性的问题。将这一部分内容单独成篇的目的也是为了与广大博友广泛的讨论一下这个问题。为了能让更多的人看到这篇文章，请各位博友看完文章之后，点一下“顶”，让本篇文章排名尽量的靠前。笔者在此谢过。讨论命题：当一个单例的对象长久不用时，会不会被jvm的垃圾收集机制回收。        首先说一下为什么会产生这

IT职场的小菜经常有这样的疑问：        为什么一个相似的功能，大牛一会儿就搞定，然后悠闲地品着下午茶逛淘宝；而自己加班加点搞到天亮还做不完。        为什么用户提出需求变更后，大牛只需潇洒地敲敲键盘，改改配置；而自己将代码改了又改，删了又建，几乎晕厥，最后只能推翻重来。        为什么大牛写完的程序测试上线后，几乎完美运行，用户无懈可击；而自己的程序bu

肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。举例来说明接口隔离原则：

定义：一个对象应该对其他对象保持最少的了解。问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。解决方案：尽量降低类与类之间的耦合。         自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么

定义：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类。类型：创建类模式类图：抽象工厂模式与工厂方法模式的区别        抽象工厂模式是工厂方法模式的升级版本，他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。在编程中，通常一个产品结构，

java深拷贝和浅拷贝的区别（转载）Object 类的 clone方法执行特定的克隆操作。首先，如果此对象的类不能实现接口 Cloneable，则会抛出 CloneNotSupportedException。(注意：所有的数组都被视为实现接口 Cloneable)否则，此方法会创建此对象的类的一个新实例，并像通过分配，严格使用此对象相应字段的内容初始化该对象的所有字段；

1. 桥梁模式简介      桥梁模式（Bridge）是一个非常有用的模式，也是比较复杂的一个模式。熟悉这个模式对于理解面向对象的设计原则，包括"开－闭"原则(OCP)以及组合/聚合复用原则(CARP)都很有帮助。理解好这两个原则，有助于形成正确的设计思想和培养良好的设计风格。      注：《Java与模式》一书认为Bridge模式不是一个使用频率很高的模式，我不太赞同，我认为Bri