随笔-11  评论-0  文章-0  trackbacks-0
  2015年7月21日
设计模式的六大原则
     摘要: 设计模式的六大原则总原则：开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。1、单一职责原则不要存在多于一个导致类变更的原因，也就是...  阅读全文
posted @ 2015-07-21 16:44 wxb1988 阅读(203) | 评论 (0) | 编辑 收藏
  2015年7月20日
抽象工厂模式
定义：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类。

类型：创建类模式

类图：

抽象工厂模式与工厂方法模式的区别

        抽象工厂模式是工厂方法模式的升级版本，他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。在编程中，通常一个产品结构，表现为一个接口或者抽象类，也就是说，工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类，而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。

        在抽象工厂模式中，有一个产品族的概念：所谓的产品族，是指位于不同产品等级结构中功能相关联的产品组成的家族。抽象工厂模式所提供的一系列产品就组成一个产品族；而工厂方法提供的一系列产品称为一个等级结构。我们依然拿生产汽车的例子来说明他们之间的区别。

        在上面的类图中，两厢车和三厢车称为两个不同的等级结构；而2.0排量车和2.4排量车则称为两个不同的产品族。再具体一点，2.0排量两厢车和2.4排量两厢车属于同一个等级结构，2.0排量三厢车和2.4排量三厢车属于另一个等级结构；而2.0排量两厢车和2.0排量三厢车属于同一个产品族，2.4排量两厢车和2.4排量三厢车属于另一个产品族。

        明白了等级结构和产品族的概念，就理解工厂方法模式和抽象工厂模式的区别了，如果工厂的产品全部属于同一个等级结构，则属于工厂方法模式；如果工厂的产品来自多个等级结构，则属于抽象工厂模式。在本例中，如果一个工厂模式提供2.0排量两厢车和2.4排量两厢车，那么他属于工厂方法模式；如果一个工厂模式是提供2.4排量两厢车和2.4排量三厢车两个产品，那么这个工厂模式就是抽象工厂模式，因为他提供的产品是分属两个不同的等级结构。当然，如果一个工厂提供全部四种车型的产品，因为产品分属两个等级结构，他当然也属于抽象工厂模式了。

抽象工厂模式代码

  1. interface IProduct1 {  
  2.     public void show();  
  3. }  
  4. interface IProduct2 {  
  5.     public void show();  
  6. }  
  7.   
  8. class Product1 implements IProduct1 {  
  9.     public void show() {  
  10.         System.out.println("这是1型产品");  
  11.     }  
  12. }  
  13. class Product2 implements IProduct2 {  
  14.     public void show() {  
  15.         System.out.println("这是2型产品");  
  16.     }  
  17. }  
  18.   
  19. interface IFactory {  
  20.     public IProduct1 createProduct1();  
  21.     public IProduct2 createProduct2();  
  22. }  
  23. class Factory implements IFactory{  
  24.     public IProduct1 createProduct1() {  
  25.         return new Product1();  
  26.     }  
  27.     public IProduct2 createProduct2() {  
  28.         return new Product2();  
  29.     }  
  30. }  
  31.   
  32. public class Client {  
  33.     public static void main(String[] args){  
  34.         IFactory factory = new Factory();  
  35.         factory.createProduct1().show();  
  36.         factory.createProduct2().show();  
  37.     }  
  38. }  

抽象工厂模式的优点

        抽象工厂模式除了具有工厂方法模式的优点外，最主要的优点就是可以在类的内部对产品族进行约束。所谓的产品族，一般或多或少的都存在一定的关联，抽象工厂模式就可以在类内部对产品族的关联关系进行定义和描述，而不必专门引入一个新的类来进行管理。

 

抽象工厂模式的缺点

       产品族的扩展将是一件十分费力的事情，假如产品族中需要增加一个新的产品，则几乎所有的工厂类都需要进行修改。所以使用抽象工厂模式时，对产品等级结构的划分是非常重要的。

 

适用场景

       当需要创建的对象是一系列相互关联或相互依赖的产品族时，便可以使用抽象工厂模式。说的更明白一点，就是一个继承体系中，如果存在着多个等级结构（即存在着多个抽象类），并且分属各个等级结构中的实现类之间存在着一定的关联或者约束，就可以使用抽象工厂模式。假如各个等级结构中的实现类之间不存在关联或约束，则使用多个独立的工厂来对产品进行创建，则更合适一点。

 

总结

       无论是简单工厂模式，工厂方法模式，还是抽象工厂模式，他们都属于工厂模式，在形式和特点上也是极为相似的，他们的最终目的都是为了解耦。在使用时，我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式，因为他们之间的演变常常是令人琢磨不透的。经常你会发现，明明使用的工厂方法模式，当新需求来临，稍加修改，加入了一个新方法后，由于类中的产品构成了不同等级结构中的产品族，它就变成抽象工厂模式了；而对于抽象工厂模式，当减少一个方法使的提供的产品不再构成产品族之后，它就演变成了工厂方法模式。

       所以，在使用工厂模式时，只需要关心降低耦合度的目的是否达到了。

posted @ 2015-07-20 22:34 wxb1988 阅读(189) | 评论 (0) | 编辑 收藏
工厂方法模式（3）

定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类。

类型：创建类模式

类图：

工厂方法模式代码

  1. interface IProduct {  
  2.     public void productMethod();  
  3. }  
  4.   
  5. class Product implements IProduct {  
  6.     public void productMethod() {  
  7.         System.out.println("产品");  
  8.     }  
  9. }  
  10.   
  11. interface IFactory {  
  12.     public IProduct createProduct();  
  13. }  
  14.   
  15. class Factory implements IFactory {  
  16.     public IProduct createProduct() {  
  17.         return new Product();  
  18.     }  
  19. }  
  20.   
  21. public class Client {  
  22.     public static void main(String[] args) {  
  23.         IFactory factory = new Factory();  
  24.         IProduct prodect = factory.createProduct();  
  25.         prodect.productMethod();  
  26.     }  
  27. }  

工厂模式：

        首先需要说一下工厂模式。工厂模式根据抽象程度的不同分为三种：简单工厂模式（也叫静态工厂模式）、本文所讲述的工厂方法模式、以及抽象工厂模式。工厂模式是编程中经常用到的一种模式。它的主要优点有：

  • 可以使代码结构清晰，有效地封装变化。在编程中，产品类的实例化有时候是比较复杂和多变的，通过工厂模式，将产品的实例化封装起来，使得调用者根本无需关心产品的实例化过程，只需依赖工厂即可得到自己想要的产品。
  • 对调用者屏蔽具体的产品类。如果使用工厂模式，调用者只关心产品的接口就可以了，至于具体的实现，调用者根本无需关心。即使变更了具体的实现，对调用者来说没有任何影响。
  • 降低耦合度。产品类的实例化通常来说是很复杂的，它需要依赖很多的类，而这些类对于调用者来说根本无需知道，如果使用了工厂方法，我们需要做的仅仅是实例化好产品类，然后交给调用者使用。对调用者来说，产品所依赖的类都是透明的。

 

工厂方法模式：

       通过工厂方法模式的类图可以看到，工厂方法模式有四个要素：

  • 工厂接口。工厂接口是工厂方法模式的核心，与调用者直接交互用来提供产品。在实际编程中，有时候也会使用一个抽象类来作为与调用者交互的接口，其本质上是一样的。
  • 工厂实现。在编程中，工厂实现决定如何实例化产品，是实现扩展的途径，需要有多少种产品，就需要有多少个具体的工厂实现。
  • 产品接口。产品接口的主要目的是定义产品的规范，所有的产品实现都必须遵循产品接口定义的规范。产品接口是调用者最为关心的，产品接口定义的优劣直接决定了调用者代码的稳定性。同样，产品接口也可以用抽象类来代替，但要注意最好不要违反里氏替换原则。
  • 产品实现。实现产品接口的具体类，决定了产品在客户端中的具体行为。

        前文提到的简单工厂模式跟工厂方法模式极为相似，区别是：简单工厂只有三个要素，他没有工厂接口，并且得到产品的方法一般是静态的。因为没有工厂接口，所以在工厂实现的扩展性方面稍弱，可以算所工厂方法模式的简化版，关于简单工厂模式，在此一笔带过。

      

适用场景：

        不管是简单工厂模式，工厂方法模式还是抽象工厂模式，他们具有类似的特性，所以他们的适用场景也是类似的。

        首先，作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过new就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

       其次，工厂模式是一种典型的解耦模式，迪米特法则在工厂模式中表现的尤为明显。假如调用者自己组装产品需要增加依赖关系时，可以考虑使用工厂模式。将会大大降低对象之间的耦合度。

       再次，由于工厂模式是依靠抽象架构的，它把实例化产品的任务交由实现类完成，扩展性比较好。也就是说，当需要系统有比较好的扩展性时，可以考虑工厂模式，不同的产品用不同的实现工厂来组装。

      

典型应用

       要说明工厂模式的优点，可能没有比组装汽车更合适的例子了。场景是这样的：汽车由发动机、轮、底盘组成，现在需要组装一辆车交给调用者。假如不使用工厂模式，代码如下：

  1. class Engine {  
  2.     public void getStyle(){  
  3.         System.out.println("这是汽车的发动机");  
  4.     }  
  5. }  
  6. class Underpan {  
  7.     public void getStyle(){  
  8.         System.out.println("这是汽车的底盘");  
  9.     }  
  10. }  
  11. class Wheel {  
  12.     public void getStyle(){  
  13.         System.out.println("这是汽车的轮胎");  
  14.     }  
  15. }  
  16. public class Client {  
  17.     public static void main(String[] args) {  
  18.         Engine engine = new Engine();  
  19.         Underpan underpan = new Underpan();  
  20.         Wheel wheel = new Wheel();  
  21.         ICar car = new Car(underpan, wheel, engine);  
  22.         car.show();  
  23.     }  
  24. }  


        可以看到，调用者为了组装汽车还需要另外实例化发动机、底盘和轮胎，而这些汽车的组件是与调用者无关的，严重违反了迪米特法则，耦合度太高。并且非常不利于扩展。另外，本例中发动机、底盘和轮胎还是比较具体的，在实际应用中，可能这些产品的组件也都是抽象的，调用者根本不知道怎样组装产品。假如使用工厂方法的话，整个架构就显得清晰了许多。

  1. interface IFactory {  
  2.     public ICar createCar();  
  3. }  
  4. class Factory implements IFactory {  
  5.     public ICar createCar() {  
  6.         Engine engine = new Engine();  
  7.         Underpan underpan = new Underpan();  
  8.         Wheel wheel = new Wheel();  
  9.         ICar car = new Car(underpan, wheel, engine);  
  10.         return car;  
  11.     }  
  12. }  
  13. public class Client {  
  14.     public static void main(String[] args) {  
  15.         IFactory factory = new Factory();  
  16.         ICar car = factory.createCar();  
  17.         car.show();  
  18.     }  
  19. }  

        使用工厂方法后，调用端的耦合度大大降低了。并且对于工厂来说，是可以扩展的，以后如果想组装其他的汽车，只需要再增加一个工厂类的实现就可以。无论是灵活性还是稳定性都得到了极大的提高。

posted @ 2015-07-20 22:32 wxb1988 阅读(197) | 评论 (0) | 编辑 收藏
单例模式（2）
定义：确保一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

类型：创建类模式

类图：

类图知识点：

1.类图分为三部分，依次是类名、属性、方法

2.以<<开头和以>>结尾的为注释信息

3.修饰符+代表public，-代表private，#代表protected，什么都没有代表包可见。

4.带下划线的属性或方法代表是静态的。

5.对类图中对象的关系不熟悉的朋友可以参考文章：设计模式中类的关系。

单例模式应该是23种设计模式中最简单的一种模式了。它有以下几个要素：

  • 私有的构造方法
  • 指向自己实例的私有静态引用
  • 以自己实例为返回值的静态的公有的方法

        单例模式根据实例化对象时机的不同分为两种：一种是饿汉式单例，一种是懒汉式单例。饿汉式单例在单例类被加载时候，就实例化一个对象交给自己的引用；而懒汉式在调用取得实例方法的时候才会实例化对象。代码如下：

饿汉式单例

  1. public class Singleton {  
  2.     private static Singleton singleton = new Singleton();  
  3.     private Singleton(){}  
  4.     public static Singleton getInstance(){  
  5.         return singleton;  
  6.     }  
  7. }  

懒汉式单例

  1. public class Singleton {  
  2.     private static Singleton singleton;  
  3.     private Singleton(){}  
  4.       
  5.     public static synchronized Singleton getInstance(){  
  6.         if(singleton==null){  
  7.             singleton = new Singleton();  
  8.         }  
  9.         return singleton;  
  10.     }  
  11. }  

单例模式的优点：

  • 在内存中只有一个对象，节省内存空间。
  • 避免频繁的创建销毁对象，可以提高性能。
  • 避免对共享资源的多重占用。
  • 可以全局访问。

适用场景：由于单例模式的以上优点，所以是编程中用的比较多的一种设计模式。我总结了一下我所知道的适合使用单例模式的场景：

  • 需要频繁实例化然后销毁的对象。
  • 创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
  • 有状态的工具类对象。
  • 频繁访问数据库或文件的对象。
  • 以及其他我没用过的所有要求只有一个对象的场景。

单例模式注意事项：

  • 只能使用单例类提供的方法得到单例对象，不要使用反射，否则将会实例化一个新对象。
  • 不要做断开单例类对象与类中静态引用的危险操作。
  • 多线程使用单例使用共享资源时，注意线程安全问题。

关于java中单例模式的一些争议：

单例模式的对象长时间不用会被jvm垃圾收集器收集吗

        看到不少资料中说：如果一个单例对象在内存中长久不用，会被jvm认为是一个垃圾，在执行垃圾收集的时候会被清理掉。对此这个说法，笔者持怀疑态度，笔者本人的观点是：在hotspot虚拟机1.6版本中，除非人为地断开单例中静态引用到单例对象的联接，否则jvm垃圾收集器是不会回收单例对象的。

对于这个争议，笔者单独写了一篇文章进行讨论，如果您有不同的观点或者有过这方面的经历请进入文章单例模式讨论篇：单例模式与垃圾收集参与讨论。

 

在一个jvm中会出现多个单例吗

        在分布式系统、多个类加载器、以及序列化的的情况下，会产生多个单例，这一点是无庸置疑的。那么在同一个jvm中，会不会产生单例呢？使用单例提供的getInstance()方法只能得到同一个单例，除非是使用反射方式，将会得到新的单例。代码如下

  1. Class c = Class.forName(Singleton.class.getName());  
  2. Constructor ct = c.getDeclaredConstructor();  
  3. ct.setAccessible(true);  
  4. Singleton singleton = (Singleton)ct.newInstance();  

这样，每次运行都会产生新的单例对象。所以运用单例模式时，一定注意不要使用反射产生新的单例对象。

 

懒汉式单例线程安全吗

        主要是网上的一些说法，懒汉式的单例模式是线程不安全的，即使是在实例化对象的方法上加synchronized关键字，也依然是危险的，但是笔者经过编码测试，发现加synchronized关键字修饰后，虽然对性能有部分影响，但是却是线程安全的，并不会产生实例化多个对象的情况。

 

单例模式只有饿汉式和懒汉式两种吗

        饿汉式单例和懒汉式单例只是两种比较主流和常用的单例模式方法，从理论上讲，任何可以实现一个类只有一个实例的设计模式，都可以称为单例模式。

 

单例类可以被继承吗

        饿汉式单例和懒汉式单例由于构造方法是private的，所以他们都是不可继承的，但是其他很多单例模式是可以继承的，例如登记式单例。

 

饿汉式单例好还是懒汉式单例好

        在java中，饿汉式单例要优于懒汉式单例。C++中则一般使用懒汉式单例。

单例模式比较简单，在此就不举例代码演示了。

单例模式与垃圾回收

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


讨论命题：当一个单例的对象长久不用时，会不会被jvm的垃圾收集机制回收。

        首先说一下为什么会产生这一疑问，笔者本人再此之前从来没有考虑过垃圾回收对单例模式的影响，直到去年读了一本书，《设计模式之禅》秦小波著。在书中提到在j2ee应用中，jvm垃圾回收机制会把长久不用的单例类对象当作垃圾，并在cpu空闲的时候对其进行回收。之前读过的几本设计模式的书，包括《java与模式》，书中都没有提到jvm垃圾回收机制对单例的影响。并且在工作过程中，也没有过单例对象被回收的经历，加上工作中很多前辈曾经告诫过笔者：尽量不要声明太多的静态属性，因为这些静态属性被加载后不会被释放。因此对jvm垃圾收集会回收单例对象这一说法持怀疑态度。渐渐地，发现在同事中和网上的技术人员中，对这一问题也基本上是鲜明的对立两派。那么到底jvm会不会回收长久不用的单例对象呢。

        对这一问题，笔者本人的观点是：不会回收。

下面给出本人的测试代码

  1. class Singleton {  
  2.     private byte[] a = new byte[6*1024*1024];  
  3.     private static Singleton singleton = new Singleton();  
  4.     private Singleton(){}  
  5.       
  6.     public static Singleton getInstance(){  
  7.         return singleton;  
  8.     }  
  9. }  
  10.   
  11. class Obj {  
  12.     private byte[] a = new byte[3*1024*1024];  
  13. }  
  14.   
  15. public class Client{  
  16.     public static void main(String[] args) throws Exception{  
  17.         Singleton.getInstance();  
  18.         while(true){  
  19.             new Obj();  
  20.         }  
  21.     }  
  22. }  

        本段程序的目的是模拟j2ee容器，首先实例化单例类，这个单例类占6M内存，然后程序进入死循环，不断的创建对象，逼迫jvm进行垃圾回收，然后观察垃圾收集信息，如果进行垃圾收集后，内存仍然大于6M，则说明垃圾回收不会回收单例对象。

        运行本程序使用的虚拟机是hotspot虚拟机，也就是我们使用的最多的java官方提供的虚拟机，俗称jdk，版本是jdk1.6.0_12

        运行时vm arguments参数为：-verbose:gc -Xms20M -Xmx20M，意思是每次jvm进行垃圾回收时显示内存信息，jvm的内存设为固定20M。

运行结果：

……

[Full GC 18566K->6278K(20352K), 0.0101066 secs]

[GC 18567K->18566K(20352K), 0.0001978 secs]

[Full GC 18566K->6278K(20352K), 0.0088229 secs]

……

        从运行结果中可以看到总有6M空间没有被收集。因此，笔者认为，至少在hotspot虚拟机中，垃圾回收是不会回收单例对象的。

        后来查阅了一些相关的资料，hotspot虚拟机的垃圾收集算法使用根搜索算法。这个算法的基本思路是：对任何“活”的对象，一定能最终追溯到其存活在堆栈或静态存储区之中的引用。通过一系列名为根（GC Roots）的引用作为起点，从这些根开始搜索，经过一系列的路径，如果可以到达java堆中的对象，那么这个对象就是“活”的，是不可回收的。可以作为根的对象有：

  • 虚拟机栈（栈桢中的本地变量表）中的引用的对象。
  • 方法区中的类静态属性引用的对象。
  • 方法区中的常量引用的对象。
  • 本地方法栈中JNI的引用的对象。

        方法区是jvm的一块内存区域，用来存放类相关的信息。很明显，java中单例模式创建的对象被自己类中的静态属性所引用，符合第二条，因此，单例对象不会被jvm垃圾收集。

        虽然jvm堆中的单例对象不会被垃圾收集，但是单例类本身如果长时间不用会不会被收集呢？因为jvm对方法区也是有垃圾收集机制的。如果单例类被收集，那么堆中的对象就会失去到根的路径，必然会被垃圾收集掉。对此，笔者查阅了hotspot虚拟机对方法区的垃圾收集方法，jvm卸载类的判定条件如下：

  • 该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例。
  • 加载该类的ClassLoader已经被回收。
  • 该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。

        只有三个条件都满足，jvm才会在垃圾收集的时候卸载类。显然，单例的类不满足条件一，因此单例类也不会被卸载。也就是说，只要单例类中的静态引用指向jvm堆中的单例对象，那么单例类和单例对象都不会被垃圾收集，依据根搜索算法，对象是否会被垃圾收集与未被使用时间长短无关，仅仅在于这个对象是不是“活”的。假如一个对象长久未使用而被回收，那么收集算法应该是最近最长未使用算法，最近最长未使用算法一般用在操作系统的内外存交换中，如果用在虚拟机垃圾回收中，岂不是太不安全了？以上是笔者的观点。

        因此笔者的观点是：在hotspot虚拟机1.6版本中，除非人为地断开单例中静态引用到单例对象的联接，否则jvm垃圾收集器是不会回收单例对象的。

posted @ 2015-07-20 22:30 wxb1988 阅读(207) | 评论 (0) | 编辑 收藏
单例模式（1）
     摘要: 单例对象（Singleton）是一种常用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。这样的模式有几个好处：1、某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。2、省去了new操作符，降低了系统内存的使用频率，减轻GC压力。3、有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同...  阅读全文
posted @ 2015-07-20 22:28 wxb1988 阅读(168) | 评论 (0) | 编辑 收藏
工厂方法模式（1）
     摘要: 8.1 女娲造人的故事      东汉《风俗通》记录了一则神话故事：“开天辟辟，未有人民，女娲搏，黄土作人……”，讲述的内容就是大家非常熟悉的女娲造人的故事。开天辟地之初，大地上并没有生物，只有苍茫大地，纯粹而洁净的自然环境，寂静而又寂寞，于是女娲决定创造一个新物种（即人类）来增加世界的繁荣，怎么制造...  阅读全文
posted @ 2015-07-20 22:20 wxb1988 阅读(168) | 评论 (0) | 编辑 收藏
工厂方法模式(2)

工厂方法模式（Factory Method）

简单工厂模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，如何解决？就用到工厂方法模式，创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。

请看例子：

  1. public interface Sender {  
  2.     public void Send();  
  3. }  

两个实现类：

  1. public class MailSender implements Sender {  
  2.     @Override  
  3.     public void Send() {  
  4.         System.out.println("this is mailsender!");  
  5.     }  
  6. }  
  1. public class SmsSender implements Sender {  
  2.   
  3.     @Override  
  4.     public void Send() {  
  5.         System.out.println("this is sms sender!");  
  6.     }  
  7. }  

两个工厂类：

  1. public class SendMailFactory implements Provider {  
  2.       
  3.     @Override  
  4.     public Sender produce(){  
  5.         return new MailSender();  
  6.     }  
  7. }  
  1. public class SendSmsFactory implements Provider{  
  2.   
  3.     @Override  
  4.     public Sender produce() {  
  5.         return new SmsSender();  
  6.     }  
  7. }  

在提供一个接口：

  1. public interface Provider {  
  2.     public Sender produce();  
  3. }  

测试类：

  1. public class Test {  
  2.   
  3.     public static void main(String[] args) {  
  4.         Provider provider = new SendMailFactory();  
  5.         Sender sender = provider.produce();  
  6.         sender.Send();  
  7.     }  
  8. }  

其实这个模式的好处就是，如果你现在想增加一个功能：发及时信息，则只需做一个实现类，实现Sender接口，同时做一个工厂类，实现Provider接口，就OK了，无需去改动现成的代码。这样做，拓展性较好！



2、抽象工厂模式

工厂方法模式和抽象工厂模式不好分清楚，他们的区别如下：

工厂方法模式： 一个抽象产品类，可以派生出多个具体产品类。    一个抽象工厂类，可以派生出多个具体工厂类。    每个具体工厂类只能创建一个具体产品类的实例。  抽象工厂模式： 多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。    一个抽象工厂类，可以派生出多个具体工厂类。    每个具体工厂类可以创建多个具体产品类的实例，也就是创建的是一个产品线下的多个产品。         区别： 工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。    工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。
工厂方法创建 "一种" 产品，他的着重点在于"怎么创建"，也就是说如果你开发，你的大量代码很可能围绕着这种产品的构造，初始化这些细节上面。也因为如此，类似的产品之间有很多可以复用的特征，所以会和模版方法相随。 

抽象工厂需要创建一些列产品，着重点在于"创建哪些"产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。

对于java来说，你能见到的大部分抽象工厂模式都是这样的： ---它的里面是一堆工厂方法，每个工厂方法返回某种类型的对象。  比如说工厂可以生产鼠标和键盘。那么抽象工厂的实现类（它的某个具体子类）的对象都可以生产鼠标和键盘，但可能工厂A生产的是罗技的键盘和鼠标，工厂B是微软的。  这样A和B就是工厂，对应于抽象工厂； 每个工厂生产的鼠标和键盘就是产品，对应于工厂方法；  用了工厂方法模式，你替换生成键盘的工厂方法，就可以把键盘从罗技换到微软。但是用了抽象工厂模式，你只要换家工厂，就可以同时替换鼠标和键盘一套。如果你要的产品有几十个，当然用抽象工厂模式一次替换全部最方便（这个工厂会替你用相应的工厂方法）  所以说抽象工厂就像工厂，而工厂方法则像是工厂的一种产品生产线
posted @ 2015-07-20 22:20 wxb1988 阅读(157) | 评论 (0) | 编辑 收藏
简单工厂模式(2)

简单工厂模式

简单工厂模式模式分为三种：

01、普通

就是建立一个工厂类，对实现了同一接口的一些类进行实例的创建。首先看下关系图：

举例如下：（我们举一个发送邮件和短信的例子）

首先，创建二者的共同接口：

  1. public interface Sender {  
  2.     public void Send();  
  3. }  

其次，创建实现类：

  1. public class MailSender implements Sender {  
  2.     @Override  
  3.     public void Send() {  
  4.         System.out.println("this is mailsender!");  
  5.     }  
  6. }  
  1. public class SmsSender implements Sender {  
  2.   
  3.     @Override  
  4.     public void Send() {  
  5.         System.out.println("this is sms sender!");  
  6.     }  
  7. }  

最后，建工厂类：

  1. public class SendFactory {  
  2.   
  3.     public Sender produce(String type) {  
  4.         if ("mail".equals(type)) {  
  5.             return new MailSender();  
  6.         } else if ("sms".equals(type)) {  
  7.             return new SmsSender();  
  8.         } else {  
  9.             System.out.println("请输入正确的类型!");  
  10.             return null;  
  11.         }  
  12.     }  
  13. }  

我们来测试下：

  1. public class FactoryTest {  
  2.   
  3.     public static void main(String[] args) {  
  4.         SendFactory factory = new SendFactory();  
  5.         Sender sender = factory.produce("sms");  
  6.         sender.Send();  
  7.     }  
  8. }  

输出：this is sms sender!

02、多个方法

是对普通工厂方法模式的改进，在普通工厂方法模式中，如果传递的字符串出错，则不能正确创建对象，而多个工厂方法模式是提供多个工厂方法，分别创建对象。关系图：

将上面的代码做下修改，改动下SendFactory类就行，如下：

[java] view plaincopypublic class SendFactory {  
   public Sender produceMail(){  
  1.         return new MailSender();  
  2.     }  
  3.       
  4.     public Sender produceSms(){  
  5.         return new SmsSender();  
  6.     }  
  7. }  

测试类如下：

  1. public class FactoryTest {  
  2.   
  3.     public static void main(String[] args) {  
  4.         SendFactory factory = new SendFactory();  
  5.         Sender sender = factory.produceMail();  
  6.         sender.Send();  
  7.     }  
  8. }  

输出：this is mailsender!

03、多个静态方法

将上面的多个工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。

  1. public class SendFactory {  
  2.       
  3.     public static Sender produceMail(){  
  4.         return new MailSender();  
  5.     }  
  6.       
  7.     public static Sender produceSms(){  
  8.         return new SmsSender();  
  9.     }  
  10. }  
  1. public class FactoryTest {  
  2.   
  3.     public static void main(String[] args) {      
  4.         Sender sender = SendFactory.produceMail();  
  5.         sender.Send();  
  6.     }  
  7. }  

输出：this is mailsender!

总体来说，工厂模式适合：凡是出现了大量的产品需要创建，并且具有共同的接口时，可以通过工厂方法模式进行创建。在以上的三种模式中，第一种如果传入的字符串有误，不能正确创建对象，第三种相对于第二种，不需要实例化工厂类，所以，大多数情况下，我们会选用第三种——静态工厂方法模式。

posted @ 2015-07-20 22:05 wxb1988 阅读(165) | 评论 (0) | 编辑 收藏
简单工厂模式(1)

简单工厂模式解释： 

       简单工厂模式（Simple Factory Pattern）属于类的创新型模式，又叫静态工厂方法模式（Static FactoryMethod Pattern）,是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

简单工厂模式的UML图： 

       简单工厂模式中包含的角色及其相应的职责如下：

       工厂角色（Creator）：这是简单工厂模式的核心，由它负责创建所有的类的内部逻辑。当然工厂类必须能够被外界调用，创建所需要的产品对象。

       抽象（Product）产品角色：简单工厂模式所创建的所有对象的父类，注意，这里的父类可以是接口也可以是抽象类，它负责描述所有实例所共有的公共接口。

       具体产品（Concrete Product）角色：简单工厂所创建的具体实例对象，这些具体的产品往往都拥有共同的父类。

简单工厂模式深入分析：

       简单工厂模式解决的问题是如何去实例化一个合适的对象。

       简单工厂模式的核心思想就是：有一个专门的类来负责创建实例的过程。

       具体来说，把产品看着是一系列的类的集合，这些类是由某个抽象类或者接口派生出来的一个对象树。而工厂类用来产生一个合适的对象来满足客户的要求。

       如果简单工厂模式所涉及到的具体产品之间没有共同的逻辑，那么我们就可以使用接口来扮演抽象产品的角色；如果具体产品之间有功能的逻辑或，我们就必须把这些共同的东西提取出来，放在一个抽象类中，然后让具体产品继承抽象类。为实现更好复用的目的，共同的东西总是应该抽象出来的。

       在实际的的使用中，抽闲产品和具体产品之间往往是多层次的产品结构，如下图所示：

简单工厂模式使用场景分析及代码实现： 

       GG请自己的女朋友和众多美女吃饭，但是GG自己是不会做饭的或者做的饭很不好，这说明GG不用自己去创建各种食物的对象；各个美女都有各自的爱好，到麦当劳后她们喜欢吃什么直接去点就行了，麦当劳就是生产各种食物的工厂，这时候GG不用自己动手，也可以请这么多美女吃饭，所要做的就是买单O(∩_∩)O哈哈~,其UML图如下所示：

       实现代码如下：

       新建立一个食物的接口：

package com.diermeng.designPattern.SimpleFactory;

 

/*

 * 产品的抽象接口

 */

public interface Food {

    /*

     * 获得相应的食物

     */

    public void get();

}

接下来建立具体的产品：麦香鸡和薯条

package com.diermeng.designPattern.SimpleFactory.impl;

import com.diermeng.designPattern.SimpleFactory.Food;

 

/*

 * 麦香鸡对抽象产品接口的实现

 */

public class McChicken implements Food{

    /*

     * 获取一份麦香鸡

     */

    public void get(){

        System.out.println("我要一份麦香鸡");

    }

}

package com.diermeng.designPattern.SimpleFactory.impl;

import com.diermeng.designPattern.SimpleFactory.Food;

 

/*

 * 薯条对抽象产品接口的实现

 */

public class Chips implements Food{

    /*

     * 获取一份薯条

     */

    public void get(){

        System.out.println("我要一份薯条");

    }

}

现在建立一个食物加工工厂：

package com.diermeng.designPattern.SimpleFactory.impl;

import com.diermeng.designPattern.SimpleFactory.Food;

 

 

public class FoodFactory {

 

    public static Food getFood(String type) throws InstantiationException, IllegalAccessException, ClassNotFoundException {

        if(type.equalsIgnoreCase("mcchicken")) {

            return McChicken.class.newInstance();

 

        } else if(type.equalsIgnoreCase("chips")) {

            return Chips.class.newInstance();

        } else {

            System.out.println("哎呀！找不到相应的实例化类啦！");

            return null;

        }

 

 

    }

}

最后我们建立测试客户端：

package com.diermeng.designPattern.SimpleFactory.client;

import com.diermeng.designPattern.SimpleFactory.Food;

import com.diermeng.designPattern.SimpleFactory.impl.FoodFactory;

 

/*

 * 测试客户端

 */

public class SimpleFactoryTest {

    public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {

 

        //实例化各种食物

        Food mcChicken = FoodFactory.getFood("McChicken");

        Food chips = FoodFactory.getFood("Chips");

        Food eggs = FoodFactory.getFood("Eggs");

 

        //获取食物

        if(mcChicken!=null){

            mcChicken.get();

        }

        if(chips!=null){

            chips.get();

        }

        if(eggs!=null){

            eggs.get();

        }

 

 

    }

}

输出的结果如下：

哎呀！找不到相应的实例化类啦！

我要一份麦香鸡

我要一份薯条

简单工厂模式的优缺点分析： 

       优点：工厂类是整个模式的关键所在。它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。

      缺点：由于工厂类集中了所有实例的创建逻辑，这就直接导致一旦这个工厂出了问题，所有的客户端都会受到牵连；而且由于简单工厂模式的产品室基于一个共同的抽象类或者接口，这样一来，但产品的种类增加的时候，即有不同的产品接口或者抽象类的时候，工厂类就需要判断何时创建何种种类的产品，这就和创建何种种类产品的产品相互混淆在了一起，违背了单一职责，导致系统丧失灵活性和可维护性。而且更重要的是，简单工厂模式违背了“开放封闭原则”，就是违背了“系统对扩展开放，对修改关闭”的原则，因为当我新增加一个产品的时候必须修改工厂类，相应的工厂类就需要重新编译一遍。

      总结一下：简单工厂模式分离产品的创建者和消费者，有利于软件系统结构的优化；但是由于一切逻辑都集中在一个工厂类中，导致了没有很高的内聚性，同时也违背了“开放封闭原则”。另外，简单工厂模式的方法一般都是静态的，而静态工厂方法是无法让子类继承的，因此，简单工厂模式无法形成基于基类的继承树结构。

简单工厂模式的实际应用简介： 

       作为一个最基本和最简单的设计模式，简单工厂模式却有很非常广泛的应用，我们这里以Java中的JDBC操作数据库为例来说明。

        JDBC是SUN公司提供的一套数据库编程接口API，它利用Java语言提供简单、一致的方式来访问各种关系型数据库。Java程序通过JDBC可以执行SQL语句，对获取的数据进行处理，并将变化了的数据存回数据库，因此，JDBC是Java应用程序与各种关系数据进行对话的一种机制。用JDBC进行数据库访问时，要使用数据库厂商提供的驱动程序接口与数据库管理系统进行数据交互。

客户端要使用使用数据时，只需要和工厂进行交互即可，这就导致操作步骤得到极大的简化，操作步骤按照顺序依次为：注册并加载数据库驱动，一般使用Class.forName();创建与数据库的链接Connection对象；创建SQL语句对象preparedStatement(sql)；提交SQL语句，根据实际情况使用executeQuery()或者executeUpdate()；显示相应的结果；关闭数据库。

posted @ 2015-07-20 21:58 wxb1988 阅读(180) | 评论 (0) | 编辑 收藏
  2015年7月19日
UML类图几种关系的总结

 在UML类图中，常见的有以下几种关系: 泛化（Generalization）,  实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

         1. 泛化（Generalization）

        【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

        【箭头指向】：带三角箭头的实线，箭头指向父类

UML类图几种关系的总结 

        2. 实现（Realization）

        【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现.

        【箭头指向】：带三角箭头的虚线，箭头指向接口

UML类图几种关系的总结 

        3. 关联（Association)

        【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

        【代码体现】：成员变量

        【箭头及指向】：带普通箭头的实心线，指向被拥有者

UML类图几种关系的总结 

        上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。 

        下图为自身关联： 

UML类图几种关系的总结

        4. 聚合（Aggregation）

        【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。

        聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

        【代码体现】：成员变量

        【箭头及指向】：带空心菱形的实心线，菱形指向整体

UML类图几种关系的总结 

        5. 组合(Composition)

        【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。

       组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向整体

UML类图几种关系的总结

        6. 依赖(Dependency)

        【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖.

        【代码表现】：局部变量、方法的参数或者对静态方法的调用

        【箭头及指向】：带箭头的虚线，指向被使用者

UML类图几种关系的总结 

        各种关系的强弱顺序：

        泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖 

        下面这张UML图，比较形象地展示了各种类图关系：

UML类图几种关系的总结

posted @ 2015-07-19 22:39 wxb1988 阅读(148) | 评论 (0) | 编辑 收藏
仅列出标题  下一页
Powered by: 博客园 模板提供：沪江博客 Copyright ©2024 wxb1988