享元模式

享元模式(Flyweight Pattern)

 

享元模式的用意：

享元模式是对象的结构模式。享元模式以共享的方式高效地支持大量的细粒度对象。

享元模式能做到共享的关键是区分内蕴状态(Internal State)和外蕴状态(Extenal State).

一个内蕴状态是存储在享元对象内部的，并且是不会随改变而有所不同的，因此，一个享元可以具有内蕴状态并可以共享。

一个外蕴状态时随着环境改变而改变的、不可以共享的状态。享元对象的外蕴状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外蕴状态不可以影响享元对象的内蕴状态。换句话说，它们是相互独立的。

享元模式的种类：

根据所涉及的享元对象的内部表象，享元模式可以分成单纯享元模式和复合享元模式两种形式。下图所示是单纯享元模式的结构示意图。

 

 

 

复合享元模式的结构示意图：

 

 

 

享元模式的应用：

享元模式在编辑器系统中大量使用。一个文本编辑器往往会提供很多种字体，而通常的做法就是将每一个字母做成一个享元对象。享元对象的内蕴状态就是这个字母，而字母在文本中的位置和字模风格等其他信息则是外蕴状态。比如，字母a可能出现在文本的很多地方，虽然这些字母a的位置和字模风格不同，但是所有这些地方使用的都是同一个字母对象。这样一来，字母对象就可以在整个系统中共享。

在Java语言中，String类型就使用了享元模式，String对象是不变对象，一旦创建出来就不能改变。如果需要改变一个字符串的值，就只好创建一个新的String对象。在JVM内部，String对象都是共享的，如果一个系统中有两个String对象所包含的字符串相同的话，JVM实际上只创建一个String对象提供给两个引用，从而实现String对象的共享。String的intern()方法给出这个字符串在共享池中的唯一实例。

单纯享元模式的结构：

抽象享元角色FlyWeight

 

abstract class FlyWeight {

      

       // 一个示意性的方法，参数state是外蕴状态

       public abstract void operation(String state);

}

 

具体享元角色ConcreteFlyWeight

 

class ConcreteFlyWeight extends FlyWeight {

         private Character intrinsicState = null;

        

         /**

          *

          * @param state,内蕴状态作为参量传入

          */

         public ConcreteFlyWeight(Character state) {

                   this.intrinsicState = state;

         }

        

         /**

          * 外蕴状态作为参量传入方法中，改变方法的行为

          * 但是并不改变对象的内蕴状态

          */

         @Override

         public void operation(String state) {

                   System.out.println("/nIntrinsic State= " + intrinsicState +

                                     "," + "Extrinsin State= " + state);

         }

        

}

 

 

 

享元工厂FlyWeightFactory

 

 

 

 

 

class FlyWeightFactory {

       private static final FlyWeightFactory factory = new FlyWeightFactory();

       private Map flies = new HashMap();

      

       private FlyWeightFactory() {}

      

       public static FlyWeightFactory getInstance() {

              return factory;

       }

      

       public FlyWeight build(Character state) {

              if (flies.containsKey(state)) {

                     return (FlyWeight)flies.get(state);

              }

              FlyWeight fly = new ConcreteFlyWeight(state);

              flies.put(state, fly);

              return fly;

             

       }

      

}

 

 

测试类：

 

class Test {

                   public static void main(String[] args) {

                   // 创建一个享元工厂对象

                   FlyWeightFactory factory = FlyWeightFactory.getInstance();

                   // 向享元工厂对象请求一个内蕴状态为'a'的享元对象

                   FlyWeight fly = factory.build(new Character('a'));

                   // 以参量方式传入一个外蕴状态

                   fly.operation("First Call");

                   // 向享元工厂对象请求一个内蕴状态为'b'的享元对象

                   //fly = factory.build(new Character('b'));

                   // 以参量方式传入一个外蕴状态

                   fly.operation("Second Call");

                   FlyWeight fly2 = factory.build(new Character('a'));

                   System.out.println(fly == fly2);

         }

}

 

 

 

分析：

抽象享元角色：此角色是所有具体享元类的超类，为这些类规定出需要实现的公共接口。那些需要外蕴状态(Externel State)的操作可以通过调用商业方法以参数形式传入。

具体享元(ConcreteFlyweiht)角色：实现抽象享元角色所规定的接口，如果有内蕴状态的话，必须负责为内蕴状态提供存储空间。享元对象的内蕴状态必须与对象所处的周围环境无关，从而使得享元对象可以在系统内共享的。

享元工厂(FlyweightFactory)角色：本角色负责创建和管理享元角色。本角色必须保证享元对象可以被系统适当的共享。当一个客户端对象调用一个享元对象的时候，享元工厂角色会检查系统中是否已经有一个复合要求的享元对象。如果已经有一个符合要求享元对象。享元工厂角色就应当创建一个合适的享元对象。

客户端(Client)角色：本角色需要维护一个对所有享元对象的引用，本角色需要自行存储所有享元对象的外蕴状态。

必须指出的是，客户端不可以直接将具体的享元类实例化，而必须通过一个工厂对象，利用一个build()方法得到享元对象。一般而言，享元工厂对象在整个系统中只有一个，因此可以是单例模式。

当客户端需要享元对象的时候，需要调用享元工厂的build()方法，并传入所需的单纯享元对象的内蕴状态，又工厂方法产生所需的享元对象。

复合享元模式的结构：

示意性源代码：

抽象享元角色FlyWeight类：

 

abstract class FlyWeight {

      

       // 一个示意性的方法，参数state是外蕴状态

       public abstract void operation(String state);

}

 

 

具体享元角色：

 

class ConcreteFlyWeight extends FlyWeight {

 

       private Character intrinsicState = null;

      

       /**

        *

        * @param state,内蕴状态作为参量传入

        */

       public ConcreteFlyWeight(Character state) {

              this.intrinsicState = state;

       }

      

       /**

        * 外蕴状态作为参量传入方法中，改变方法的行为

        * 但是并不改变对象的内蕴状态

        */

       @Override

       public void operation(String state) {

              System.out.println("/nIntrinsic State= " + intrinsicState +

                            "," + "Extrinsin State= " + state);

       }

      

}

 

 

具体复合享元角色的源代码：

 

 

class ConcreteCompositeFlyweight extends FlyWeight {

   

    private Map flies = new HashMap(10);

    private FlyWeight flyWeight;

   

    /**

     * 增加一个新的单纯的享元对像到聚集中

     */

    public void add(Character key, FlyWeight fly) {

       flies.put(key, fly);

    }

   

    @Override

    public void operation(String state) {

       FlyWeight fly = null;

       for (java.util.Iterator it= flies.entrySet().iterator(); it.hasNext();) {

           Map.Entry e = (Map.Entry)it.next();

           fly = (FlyWeight)e.getValue();

           fly.operation(state);

       }

      

    }

   

}

 

 

享元模式应当在什么情况下使用：

当以下所有的条件都满足时，可以考虑使用享元模式：

◆     一个系统有大量的对象

◆     这个对象消耗大量的内存

◆     这些对象的状态中大部分都可以外部化

◆     这些对象可以按照内蕴状态分成很多的组，当吧外蕴对象从对象中剔除时，每一个组都可以仅用一个对象代替。

◆     软件系统不依赖这些对象的身份，换言之，这些对象可以是不可分割的。

满足以上的这些条件的系统可以使用享元对象。最后，使用享元模式需要维护一个记录的系统已有的所有享元的表，而这些需要消费资源，因此，应当在有足够多的享元实例可供共享时才值得使用享元模式。

怎样做到共享：

一个享元对象之所以可以被很多的用户端共享，是因为它只含有可以共享的状态，而没有不可以共享的状态，这是可以使用使用享元模式的重要前提。

因此，问题就转化为怎样才能重新设计这个常规类，使它能够符合享元类的要求。要做到这一点，需要分两步走。

1.       将可以共享的状态和不可以共享的状态从此常规类中区分开来，将不可共享的状态从类里剔除出去。

虽然有很多客户端看上去都在使用此常规类的实例，但是经过仔细考察后读者常常会发现，这些看上去似乎一样的实例其实并非具有完全相同的状态。这时就应当把这些实例的状态分为两类：一类是对所有的客户端都有相同值的状态，另一类是根据不同客户端而有不同值的状态。那些对所有的客户端都取相同的值的状态时可以共享的状态；而那些对不同的客户端有不同值的状态时不可以共享的状态；那些不可以共享的状态必须从此类中移除。

2.       这个类的创建过程必须由一个工厂对象加以控制。

为了达到共享的目的，客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。这个工厂对象应当使用一个内部列表保存所有的已经创建出来的对象。当客户端请求一个新的对象时，工厂对象首先检查列表，看看是否已经有一个对象负责创建被共享的对象。这个工厂对象应当使用一个内部列表保存所有的已经创建出来的对象。当客户端请求一个新的对象时，工厂对象首先检查列表，看是否已经有一个对象。如果已经有了，就直接返回此对象；如果没有，就创建一个新的对象。

享元模式的优点和缺点：

享元模式的优点在于它大幅度地降低内存中对象的数量。但是，它做到这一点所付出的代价也是很高的：

享元模式使得系统更加复杂，为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。

享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。