end's coding life

当对象难以访问或需要对对象的使用加以控制/限制时，可以为对象设置一个代理，代理来持有该对象的实例。对该对象的访问都经由代理对象来控制，再由代理对象去调用被代理对象的实现。这种方法，被称为代理模式。为了增加客户端对目标对象访问的透明性，目标对象和代理类要实现相同的接口，使客户端对方法的使用没有什么区别。     代理模式定义：给某一个对象提供一个代理或占位符，并由代理对象来控制对原对象的访问。

公司的一些业务类最开始的设计只实现了核心功能，在后来不断的发展中，需要对其功能进行扩展，增加诸如缓存、加密等功能。为了符合开闭原则，不对原有类进行修改。如果通过新增类继承原有类的方式，类的数量将会成几何级上涨。例如原有3个类，现在要对这些类都扩展四个新功能。那最少就要增加12个子类。臃肿、麻烦。     装饰模式可以解决这个问题。     定义： 动态地给一个对象增加一些额外的职责，就增加对象

门面模式是一个非常常用且实用的模式。在实现的系统中，通常有多个子系统或功能模块。客户端如果直接的与这些子系统打交道，将会是耦合关系和客户端代码变得很复杂。通过在子系统前加入一个门面，对外提供一个统一的入口，将会解决这个问题。 外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。     如图，

在系统特定场景的系统中，包含大量的重复的实体。如棋类游戏中的棋子，大多形状/大小/都相同；又如游戏中，大量完全相同的小怪物，外观/基础属性等也完全相同。如果每个这种实体都完全对应一个对象，那么内存中将存储大量的重复数据，浪费了资源/降低了资源利用率。     享元模式就是为了解决这个问题，它将这类重复的、不变的小粒度实体，抽象成元对象，又称为享元。存储在享元池中，然后在需要使用享元的地方拿出来用

公司发生的各种各样的事情，都需要有人来处理。比如，一个底层员工接到了一个新业务。首先他会判断这个业务的重要性和自己的职责，看看自己处理就好，还是该上报给自己的领导--部门经理。部门经理如果接到了这个消息，他也会做同样的事情，一直到公司的最高决策者都在这个链条中。     责任链模式就是处理这类事物模型的设计模式，通过把可能需要参与到处理中的对象，加入到这个链条中，交付任务的人不需要关心这个任务在

一款游戏中的某个BOSS，根据当前血量不同，有几种不同状态。满血1000时是平静状态，不会攻击玩家；小于1000大于500是攻击状态，会用普通的技能攻击离他最近的玩家；小于500大于0是狂暴状态，会发动终极技能周期性的对周围所有玩家造成大量伤害；等于0是死亡状态，会在尸体上提供随机装备给予玩家。在BOSS的技能中，有一系列的恢复技能--可以为自己加血。除了死亡时，随时可能释放。所以，除了死亡状态不

在软件设计中，有这样一种需求情况。客户端或用户可能发起一些行为，但是每个行为对应的系统中的执行对象和真正的操作不是固定的，有可能动态的根据环境改变，有可能客户端在一定的范围内自由的定制。就像你买了好多的开关回到家里，这些开关在使用之前不一定被安装到哪一个房间，也不一定用来控制哪一个电器，就算安装之后，只要你开心，也可以随意的调换他们和电器之间的关系。这和上述的软件设计中的该类需求是非常相似的。

设计模式之策略模式

上两篇文章中介绍的状态模式和策略模式结构有所类似，解决的问题的类型有所联系、又有所差异。本篇作为该设计模式系列的最后一篇模式介绍性的文章，将简单介绍访问者模式。这个模式在解决的问题的本质上，与上面两个模式还是有相同点的。状态模式是本身具有多个状态，可能由于自己的属性切换；策略模式是问题具有多种方案，可能根据环境选择不同的策略；访问者模式是问题可能被多个处理者处理。     假设一个电商平台，某后

配器模式定义如下： 适配器模式(Adapter Pattern)：将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。     从定义中，很容易理解该模式所要解决的问题和解决方法。在实际开发中，由于种种原因（可能是历史原因，可能是设计与某些外部实现不

考虑实现一个管理公司组织架构的系统，公司下可能包含子公司，子公司下包含CEO等最高管理者和部门，部门下又包含部门管理者和小部门，等等。抽象成数据结构，就是一个树形结构。     如果为每一种尸体类型都定义一个类，那至少要包括总公司/子公司/部门/员工，这四个类。每个类的所包含的成员也有很大不同，均需要定制。而且随着类型越来越多，这种组合性的复杂的是成指数上升的。     上面说的这

思考一个这样的场景，如果你是一个会变通的卖肉夹馍的商人，你觉得只卖传统的一种没有什么新意。所以你提供的馍有白吉馍、面包片、馒头片等多种类型，同时肉也分为牛肉、驴肉、猪肉等。一经上市，果然大受欢迎，卖得非常好。这时，你又开始在馍和肉上继续寻找新的原料来增加你的种类。那么问题来了，如果每天开卖之前，你都对每种馍和肉的组合（就目前种类来说就有3*3=9种）都做出 一定数量，不仅麻烦，而且不够灵活。每增加

单例模式也许是最常见的一种设计模式了。看起来简单，实际上如果不注意细节，产生的问题，相对还是有些复杂的。     在软件系统中，我们希望某些类始终保持最多一个实例对象的存在，来保证一致性或者节约内存等。这时，就用到了单例模式。     单例模式的做法是，将类的构造方法私有化，不对外开放。在类的内部定义一个该类的静态实例成员。通过一个静态方法对外提供该成员。     但这里就有一些问题了，这个

迭代器模式为对象聚合类提供了遍历操作的方式。在JDK中，内置了迭代器，就是使用了该设计模式。     设想，如果为一个对象聚合类再添加很多的遍历操作的方法，不但类变得臃肿，不符合单一职责原则，而且也不够灵活，很容易违反开闭原则。如果交给子类实现遍历方法，又需要向子类暴漏内部细节。我们来看看迭代器模式是怎样解决这个问题的。     Aggregate和Iterator为抽象聚合类和抽象迭

在软件系统中，特别是一些交互及系统中，常有互相之间包含复杂行为联系的大量对象。可以想象一下用过的许多桌面软件，常包含许多的功能模块和显示模块，用户产生一个行为时，多个模块可能都需要产生相应。     如果这些对象间都是直接的与相关的对象通信，那整个系统内的关联关系将会非常复杂，难以维护。而且耦合度很高，难以修改和扩展。如过能出现一位交警叔叔来作为这复杂的路面情况的指挥者就好了，终结者模式就是这种

很多软件如制图、文字编辑软件，都需要记住一些历史状态来提供撤销的功能。备忘录模式就是为这种情况而生的。简单结构如下：     备忘录模式(Memento Pattern)：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。它是一种对象行为型模式，其别名为Token。     简单结构如下：          Originat

观察者模式(Observer Pattern)：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式的别名包括发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。     观察

在开发过程中，经常会出现这种情况：很多功能都包含几步骤来组合完成，其中一部分步骤几乎是固定不变的，剩余部分才会根据不同情况有所差异。如果每个这种功能都吧所有步骤重新定义实现一遍，会很麻烦，重复。例如JDBC的传统使用，很多时候为了一个小操作，不得不管理连接资源的打开/关闭，异常的处理。     为了提高代码的重用性，和系统的灵活性，可以使用一种模式：模板方法模式，它就是为上述情况而设计的。在

一、简单工厂     对象的创建方式有很多，常用new来创建。但是这种做法在一些情况下，有很多不好的地方。比如创建操作散落在代码的多处、对象的创建职责和使用职责混合到一起等等。简单工厂可以一定程度上解决该问题。通常的做法是对被创建的多个类进行抽象，将公共成员和方法放到抽象类中。不同的类继承抽象类，对细节进行不同的实现。然后创建一个工厂类，将类实例化的操作封装到工厂类的静态工厂方法中，通过不同的参

原型模式(Prototype  Pattern)：使用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式是一种对象创建型模式。     原型模式，就是将一个原型对象传递给要发动创建行为的对象，要发动创建行为的对象调用原型对象的拷贝方法来实现对象的创建。它属于创建型模式，特殊的是原型类本身就是工厂，克隆方法就是工厂方法。在Java中，Object类提供了clone方法，来实现对

建造者模式也是对象创建模式，主要用于构建复杂的组成对象。既对象类由多个组件组成，如汽车由引擎/轮子/方向盘/框    架等部分组成。建造者模式的目的在于，在客户端制定特性类型的前提下，透明的创建这些组件并组成最终产品，而这一切对客户端是透明的。而且扩展不同的复杂对象类时，要易于扩展。     定义： 建造者模式(Builder Pattern)：将一个复杂对象的构建与它的表

对常见的设计模式进行通俗一定的介绍，并分别分析使用场景。将类似的模式进行对比，从多个方面分析不同的模式不同的出发点，从而达到了然于胸的目的。