二十三种设计模式-创建型

本文转自:http://blog.csdn.net/hguisu/article/details/7505909

创建型模式
1、工厂方法(Factory Method)
2、抽象工厂(Abstract Factory)
3、建造者模式(Builder)
4、单例模式(Singleton)
5、原型模式(Prototype)

 

简单工厂模式:

客户需要一款车,为了降低耦合,就出现了工厂类,把创建宝马的操作细节都放到了工厂里面去,客户直接使用工厂的创建工厂方法,传入想要的宝马车型号就行了,而不必去知道创建的细节.这就是:简单工厂模式



 代码的实现如下:

/** 
	   * 客户类
	   * 客户通过工厂获取车 
	   */  
	public class Customer {
		public BMW getBMW(int type){
			Factory factory = new Factory();
			return (BMW)factory.createBMW(type);
	    }  
	}
    //工厂类角色:这是本模式的核心,含有一定的商业逻辑和判断逻辑。
	/** 
	 * 工厂类:
	 * 工厂创建车 
	 */  
	public class Factory {
		public void createBMW(int type){  
	        switch (type) {  
	          case 320:  
	             return new BWM320();
	          case 523:  
	             return new BMW523();
	   }  
	} 
	//抽象产品角色:它一般是具体产品继承的父类或者实现的接口。
	//具体产品角色:工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。 
	/** 产品类:
	 * 车子系列 
	 */  
	public class BWM{
		public void construct(pa) {
	    }  
	}  
	public class BWM320 extends BWM{  
		public void construct(pa) {
	    } 
	}    
	public class BWM523 extends BWM{  
		public void construct(pa) {
	    } 
	}

 1、工厂方法模式

下面我们从开闭原则(对扩展开放;对修改封闭)上来分析下简单工厂模式。当客户不再满足现有的车型号的时候,想要一种速度快的新型车,只要这种车符合抽象产品制定的合同,那么只要通知工厂类知道就可以被客户使用了。所以对产品部分来说,它是符合开闭原则的;但是工厂部分好像不太理想,因为每增加一种新型车,都要在工厂类中增加相应的创建业务逻辑(createBMW(type)方法需要新增case),这显然是违背开闭原则的。可想而知对于新产品的加入,工厂类是很被动的。 
         我们举的例子是最简单的情况,而在实际应用中,很可能产品是一个多层次的树状结构。

 

 工厂方法模式去掉了简单工厂模式中工厂方法的静态属性,使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。
工厂方法模式组成:
1)抽象工厂角色: 这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
2)具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
3)抽象产品角色:它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。
4)具体产品角色:具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。 



 

创建工厂类:
 
/** 
 * 创建工厂的接口 
 * 
 */  
interface FactoryBMW {   
       function createBMW();   
}   
  
/** 
 *  
 * 创建BWM320车 
 */  
class FactoryBWM320 implements FactoryBMW {  
   function  createBMW($type){  
      return new BWM320();  
   }  
  
}  
  
/** 
 *  
 * 创建BWM523车 
 */  
class FactoryBWM523 implements FactoryBMW {  
   function  createBMW($type){  
      return new BMW523();  
   }  
}  


客户类:

/** 
 * 客户得到车 
 */  
class Customer {  
   private $BMW;  
   function  getBMW($type){  
      switch ($type) {  
        case 320:  
           $BWM320 = new FactoryBWM320();  
           return $BWM320->createBMW();  
        case 523:  
           $BWM523 = new FactoryBWM523();  
           return $BWM320->createBMW();  
            //....  
      }  
  
  }  
}  

 在下面情况下你可以考虑使用工厂方法模式:
1)当客户程序不需要知道要使用对象的创建过程。
2)客户程序使用的对象存在变动的可能,或者根本就不知道使用哪一个具体的对象。 

 

 

简单工厂模式与工厂方法模式真正的避免了代码的改动了?没有。在简单工厂模式中,新产品的加入要修改工厂角色中的判断语句;而在工厂方法模式中,要么将判 断逻辑留在抽象工厂角色中,要么在客户程序中将具体工厂角色写死(就象上面的例子一样)。而且产品对象创建条件的改变必然会引起工厂角色的修改。
 

2、抽象工厂模式

抽象工厂模式和工厂方法模式的区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。
抽象工厂模式的用意为:给客户端提供一个接口,可以创建多个产品族中的产品对象 ,而且使用抽象工厂模式还要满足一下条件:
1)系统中有多个产品族,而系统一次只可能消费其中一族产品。
2)同属于同一个产品族的产品以其使用。
抽象工厂模式的各个角色(和工厂方法一样):
1)抽象工厂角色: 这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
2)具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
3)抽象产品角色:它是具体产品继承的父类或者是实现的接口。
4)具体产品角色:具体工厂角色所创建的对象就是此角色的实例。
 

3、建造者模式(Builder)

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

在以下情况使用Builder模式

•当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

•当构造过程必须允许被构造的对象有不同的表示时。

此模式结构如下页上图所示:

 


• 抽象建造者角色(Builder):为创建一个Product对象的各个部件指定抽象接口,以规范产品对象的各个组成成分的建造。一般而言,此角色规定要实现复杂对象的哪些部分的创建,并不涉及具体的对象部件的创建。
具体建造者(ConcreteBuilder)

1)实现Builder的接口以构造和装配该产品的各个部件。即实现抽象建造者角色Builder的方法。

2)定义并明确它所创建的表示,即针对不同的商业逻辑,具体化复杂对象的各部分的创建

3) 提供一个检索产品的接口

4) 构造一个使用Builder接口的对象即在指导者的调用下创建产品实例

指导者(Director):调用具体建造者角色以创建产品对象的各个部分。指导者并没有涉及具体产品类的信息,真正拥有具体产品的信息是具体建造者对象。它只负责保证对象各部分完整创建或按某种顺序创建。

产品角色(Product:建造中的复杂对象。它要包含那些定义组件的类,包括将这些组件装配成产品的接口。

Builder模式的主要效果:

1 ) 它使你可以改变一个产品的内部表示 Builder对象提供给导向器一个构造产品的抽象接口。该接口使得生成器可以隐藏这个产品的表示和内部结构。它同时也隐藏了该产品是如何装配的。因为产品是通过抽象接口构造的,你在改变该产品的内部表示时所要做的只是定义一个新的生成器。

2) 它将构造代码和表示代码分开 Builder模式通过封装一个复杂对象的创建和表示方式提高了对象的模块性。客户不需要知道定义产品内部结构的类的所有信息;这些类是不出现在Builder接口中的。每个Concrete Builder包含了创建和装配一个特定产品的所有代码。这些代码只需要写一次;然后不同的Director可以复用它以在相同部件集合的基础上构作不同的Product。

3 ) 它使你可对构造过程进行更精细的控制 Builder模式与一下子就生成产品的创建型模式不同,它是在导向者的控制下一步一步构造产品的。仅当该产品完成时导向者才从生成器中取回它。因此Builder接口相比其他创建型模式能更好的反映产品的构造过程。这使你可以更精细的控制构建过程,从而能更精细的控制所得产品的内部结构。

 建造者模式的优点
       首先,建造者模式的封装性很好。使用建造者模式可以有效的封装变化,在使用建造者模式的场景中,一般产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。
       其次,建造者模式很容易进行扩展。如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险。
建造者模式与工厂模式的区别
      我们可以看到,建造者模式与工厂模式是极为相似的,总体上,建造者模式仅仅只比工厂模式多了一个“导演类”的角色。在建造者模式的类图中,假如把这个导演类看做是最终调用的客户端,那么图中剩余的部分就可以看作是一个简单的工厂模式了。
      与工厂模式相比,建造者模式一般用来创建更为复杂的对象,因为对象的创建过程更为复杂,因此将对象的创建过程独立出来组成一个新的类——导演类。也就是说,工厂模式是将对象的全部创建过程封装在工厂类中,由工厂类向客户端提供最终的产品;而建造者模式中,建造者类一般只提供产品类中各个组件的建造,而将具体建造过程交付给导演类。由导演类负责将各个组件按照特定的规则组建为产品,然后将组建好的产品交付给客户端。
总结
      建造者模式与工厂模式类似,他们都是建造者模式,适用的场景也很相似。一般来说,如果产品的建造很复杂,那么请用工厂模式;如果产品的建造更复杂,那么请用建造者模式。

4、单例模式(Singleton)

类构造函数私有和类自身的静态方法:让类自身负责保存它的唯一实例(静态变量)。这个类可以保证没有其他实例可以被创建(通过截取创建新对象的请求) ,并且它可以提供一个访问该实例的方法(静态方法)。这就是Singleton模式。

在下面的情况下可以使用单件模式
1)当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。

2)当这个唯一实例应该是通过子类化可扩展的,并且客户应该无需更改代码就能使用一个扩展的实例时。

public class TestSingleton {
		public static void main(String[] args) {
		}
	}
	class ClassA{ //饿汉式
		private static ClassA i = new ClassA();
		public static ClassA getClassA(){
			return i;
		}

		private ClassA(){}
	}

	class ClassB{ //懒汉式
		private static ClassB i = null;
		public static synchronized ClassB getClassB(){
			if (i == null) 
				i = new ClassB();
			return i;
		}
		private ClassB(){}
	}

 单例模式(Singleton) 改善全局变量和命名空间的冲突,可以说是一种改良了的全局变量。这种一个类只有一个实例,且提供一个访问全局点的方式,更加灵活的保证了实例的创建和访问约束。系统中只有一个实例,因此构造方法应该为私有。 饿汉式:类加载时直接创建静态实例 懒汉式:第一次需要时才创建一个实例,那么newInstance方法要加同步 饿汉式比懒汉式要好,尽管资源利用率要差。但是不用同步。


5、原型模式(Prototype)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值