设计模式

       今天我把设计模式给给大概的总结了一下，下面是其中比较重要的一些设计模式：

设计模式：

1.简单的工厂模式
   简单的工厂模式主要是把我们常用的那些new关键字给隐藏掉，然后通过工厂统一提供实例对象。
   通过工厂方法通过接口获取对象的引用。
   我们在MVC中的service层，在调用dao层的方法，写一个工厂类，里面的方法返回它的接口，实际上返回的是它的实现类，这样就
   不需要关心dao层的具体实现了，因为它会在工厂里面得到符合的对象返回实现。  

2.单例模式
  单例模式主要是使内存中保持一个对象。
  在java虚拟机里面一个类只能生成一个对象。
  public class SingletonMode {
 private static final SingletonMode instance = new SingletonMode();

 private SingletonMode() {

 }

 public static SingletonMode getInstance() {
  return instance;
 }

}

// 方法二
class Singleton {
 
 private static Singleton instance2 = null;

 public static synchronized Singleton getInstance() {

  if (instance2 == null)
   instance2 = new Singleton();
  return instance2;
 }
}

方法一 要怎么样才能生成单例类？
   1.将自己的实例对象设置为一个属性，并且要添加private、static、final等修饰符
   2.将构造函数设置为私有化的，也就是加private
   3.通过一个静态方法向外界提供这个类的实例。

3.策略模式
  定义：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

  解决问题：某个具体的解决方法有很多种可选择的实现。

  常用地方：一般hibernate和IBatis里面就使用了这个策略模式。

4.模板模式
  定义:定义一个操作中算法的骨架,将一些步骤的执行延迟到其子类中.

  解决问题：重要是解决子类之间代码或者是流程的重复问题。

  常用地方：DAO模式里面的模板类，Spring里面的常用模板，包括JdbcTemplate等等

  一句话，父类定义流程，子类实现。

5.观察者模式

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

  解决问题：解决多个对象间相互依赖关系的相互通知。

  常用地方：一些数据有多个视图的表示，譬如Java中自带的图形事件应用。

  用途：观察者模式通常与 MVC 范式有关系。在 MVC 中，观察者模式被用来降低 model 与 view 的耦合程度。一般而言， model 的改变会触发通知其他身为观察者的 model 。而这些 model 实际上是 view 。 Java Swing 就是个范例，示意了 model 预期会透过 PropertyChangeNotification 架构以送出改变的通知给其他 view 。 Model 类别是 Java bean 类别的一员，并拥有与上述目标类别同样的行为。 View 类别则系结了一些 GUI 中的可视元素，并拥有与上述观察者类别同样的行为。当应用程式在执行时。使用者将因 view 做出相应的更新而看见 model 所产生的变更。

    例子一：
　　
　　为了管理一个卖厂多个分类产品，让我们建立一个销售报表系统。这个系统有以下特征：
　　
　　（1）用户可以选择一个他们感兴趣的分类
　　
　　（2）在选择了一个分类以后，需要显示下面的两种类型的报表。
　　
　　A、月度报表（Monthly report）--所选分类当月的所有交易清单。
　　
　　B、年度累积额(YTD sales chart)--以月为单位显示选择分类的年度累积额图。
　　
　　（3）当一个不同的分类被选择时，两种报表的数据会被刷新，显示当前所选分类的报表。

    例子二：
    观察者定义了对象间一对多的关系，当一个对象的状态变化时，所有依赖它的对象都得到通知并且自动地更新。拍卖演示了这种模式。每    个投标人都有一个标有数字的牌子用于出价。拍卖师开始拍卖时，他观察是否有牌子举起出价。每次接受一个新的出价都改变了拍卖的当    前价格，并且广播给所有的投标人进行新的出价。

    在项目中怎么使用:在MVC模式中的mode层(业务逻辑层)里面的数据发生改变的话(mode也就是被观察者)，那么依赖于它的那些观察者，也就是视图层也会跟着发生改变。

6.组合模式(Composite)
  定义：将对象以树形结构组织起来,以达成“部分－整体” 的层次结构，使得客户端对单个对象和组合对象的使用具有一致性.
  解决问题：树形数据结构的方案，组合模式具有很强的层次感，一眼看上去，非常的清楚
  例子：组合模式就和一本书的目录一样。
  主要体现在树形结构里面。

7.命令模式(Command)
定义: 将来自客户端的请求传入一个对象，无需了解这个请求激活的 动作或有关接受这个请求的处理细节。

主要实现的是把客户的各种请求和操作封装到一个命令对象中，从而达到把命令的请求和对命令的
具体执行两者之间的关系相互分离的目标；同时还能对命令的请求者以统一的形式进行
命令请求（功能调用），并委派给不同的对象

解决问题:只关心行为,不关心具体执行类或者实现.
优点:解耦了发送者和接受者之间联系。 发送者调用一个操作，接受者接受请求执行相应的动作，因为使用Command模式解耦，发送者无需知道接受者任何接口。

举例说明：
我们去饭店吃饭，角色里有我，服务员，厨师（能烧多种菜)

分析：1、我是命令的请求者
      2、厨师是执行命令的对象
      3、服务员是命令控制者。
      4、我们可以定义1个抽象命令（该命令下有1系列子命令，每个子命令调用厨师的1门手艺，比如红烧猪手）

举例说明：
我们知道我们访问1个网站，网站能够同时接受的人数是有限的，我们发送的请求是1个命令，这些命令存放在命令列表里，这些命令可以被执行或是撤消。

项目中应用:在某个管理系统中，需要对每个登陆的用户进行日志记录，但是日志记录有多种形式，比如：
控制台，log4j

8.外观模式(门面模式)(Facade)
  定义：为子系统中的一组接口提供一个一致的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
  解决问题：子接口繁多，调用复杂，内部交互地方比较多
  优点：facade实际上是个理顺系统间关系,降低系统间耦合度的一个常用的办法

例子：
Facade外观模式，是一种结构型模式，它主要解决的问题是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。在这里我想举一个例子：比如，现在有一辆汽车，我们（客户程序）要启动它，那我们就要发动引擎（子系统1），使四个车轮（子系统2）转动。但是实际中我们并不需要用手推动车轮使其转动，我们踩下油门，此时汽车再根据一些其他的操作使车轮转动。油门就好比系统给我们留下的接口，不论汽车是以何种方式转动车轮，车轮变化成什么牌子的，我们要开走汽车所要做的还是踩下油门。

GoF《设计模式》中说道：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

例子二：
例如：我们知道用户、角色、权限三者关系，在早期，还没有角色的概念，只有用户和权限的概念，是直接讲权限赋予用户，但是后来为了方便管理，才引入角色的概念，把权限赋予角色，再把角色赋予用户。而角色就是我们外观模式中说的经常使用的接口，权限就是子系统，用户就是客户。

9.装饰器模式

定义：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
      动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

解决问题：一个对象需要经常动态增加属性或职责

 

10.状态模式(state)
  状态模式代替了代码中的if判断。以前，我们的状态是通过if语句来判断的，现在学习了状态模式，我们可以通过状态模式来代替以前所用的if判断。

State的定义: 不同的状态,不同的行为;或者说,每个状态有着相应的行为.

何时使用?
State模式在实际使用中比较多,适合"状态的切换".因为我们经常会使用If elseif else 进行状态切换, 如果针对状态的这样判断切换反复出现,我们就要联想到是否可以采取State模式了.

不只是根据状态,也有根据属性.如果某个对象的属性不同,对象的行为就不一样,这点在数据库系统中出现频率比较高,我们经常会在一个数据表的尾部,加上property属性含义的字段,用以标识记录中一些特殊性质的记录,这种属性的改变(切换)又是随时可能发生的,就有可能要使用State.

11.职责链模式

 定义：为了避免请求的发送者和接收者之间的耦合关系，使多个接受对象都有机会处理请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

解决问题

1 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。

2 你想在不明确指定接受者的情况下，向多个对象中的一个提交一个请求。

3 可处理一个请求的对象集合应该被动态指定。
  

12.抽象工厂模式(Abstractfactrory)

定义：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
用途
一个系统要独立于它的产品的创建、组合和表示时。
一个系统要由多个产品系列中的一个来配置时。
当你要强调一系列相关的产品对象的设计以便进行联合使用时。
当你提供一个产品类库，而只想显示它们的接口而不是实现时。

13.适配器模式 (Adapter)

定义：将一个类的接口转换成客户希望的另外一个接口Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

解决问题：已经存在类似功能的类或接口，但是方法签名不一样。

适用性：

你想使用一个已经存在的类，而它的接口不符合你的需求。
你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作。
（仅适用于对象A d a p t e r ）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。 

为何使用?
我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是：修改各自类的接口，但是如果我们没有源代码，或者，我们不愿意为了一个应用而修改各自的接口。 怎么办?

使用Adapter，在这两种接口之间创建一个混合接口(混血儿).

 

14.builder(建造)模式

Builder模式定义:
将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.

Builder模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知道内部的具体构建细节.Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到.

为何使用?
是为了将构建复杂对象的过程和它的部件解耦.注意: 是解耦过程和部件.

因为一个复杂的对象,不但有很多大量组成部分,如汽车,有很多部件:车轮 方向盘 发动机还有各种小零件等等,部件很多,但远不止这些,如何将这些部件装配成一辆汽车,这个装配过程也很复杂(需要很好的组装技术),Builder模式就是为了将部件和组装过程分开.

15.代理模式(proxy)
 代理模式主要使用的是静态代理。
设计模式中定义: 为其他对象提供一种代理以控制对这个对象的访问.

代理模式的作用是：为其他对象提供一种代理以控制对这个对象的访问。在某些情况下，一个客户不想或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。

　例如：一个显示图片的选项卡程序，每一个选项卡显示一幅图片，在任何一个时刻，只有一个选项卡被选中，因此在没有选中的选项卡中的图片就没有必要被创建，使用一个图片的代理对象代理这个图片，只要在客户端程序要求显示这个图像时才真正创建该图像，在代理对象中必须存储被代理对象的所有的信息。

总结：Proxy模式在访问对象是引入了一定程度的间接性，根据代理的类型，附加的间接性有多种用途：
　　1. Remote Proxy可以隐藏一个对象存在于不同抵制空间的事实。
　　2. Virtual Proxy可以进行最优化，例如根据要求创建对象。
　　3. Protection Proxies和Smart Reference都允许在访问一个对象时有一些附加的内务处理。

16.中介者模式(Mediator)
   定义：用一个中介对象来封装一系列关于对象交互行为.
   用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。简单点来说，将原来两个直接引用或者依赖的对象拆开，在中间加入一个“中介”对象，使得两头的对象分别和“中介”对象引用或者依赖。
   为何使用Mediator?
各个对象之间的交互操作非常多;每个对象的行为操作都依赖彼此对方,修改一个对象的行为,同时会涉及到修改很多其他对象的行为,如果使用Mediator模式,可以使各个对象间的耦合松散,只需关心和 Mediator的关系,使多对多的关系变成了一对多的关系,可以降低系统的复杂性,提高可修改扩展性.

 中介者模式的优点和缺点：
1.         减少了子类生成，Mediator将原本分布在各同事间的行为集中在一起。改变这些行为只需要生成Mediator的子类即可。这样各个Colleague类可被重用。
2.         他将各Colleague解耦， Mediator有利于各Colleague间的松耦合，你可以独立的改变和复用各Colleague类和Mediator类。
3.         它简化了对象协议， 用Mediator和各Colleague间的一对多的交互来代替多对多的交互，一对多的关系更容易理解、维护和扩展。
4.         他对对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，使你将注意力从对象各自本身的行为转移到他们之间的交互上来。
5.         它使控制集中化 中介者模式将交互的复杂性变为中介者的复杂性，因为中介者封装了协议，它可能变得比任何一个Colleague都复杂，这可能使得中介者自身变成一个难以维护的庞然大物。

 例子1：中介者模式用一个中介对象来控制一系列的对象交互。通过中介者实现各个对象之间的松散耦合，而不是彼此直接作用。机场的控制塔很好地演示了这种模式。降落或者起飞的飞机直接与塔台通讯，而不是彼此间直接通讯。谁可以起飞或降落是由塔台决定的。这里需要注意的是塔台并不控制整个飞行过程。它只负责飞机在机场附近的区域。
 例子2：是否还记得应用广泛的MVC分为哪三层？模型层（Model）、表现层（View）还有控制层（ControlMediator）。控制层便是位于表现层与模型层之间的中介者。笼统地说MVC也算是中介者模式在框架设计中的一个应用。