跟屌丝大哥学习设计模式--享元模式

四、举例
这里就以去餐馆吃饭为例详细的说明下享元模式的使用方式。去菜馆点菜吃饭的过程大家一定都是轻车熟路了，这里就不赘述。在例子中我使用了一个list来存放外蕴状态和内蕴状态的对应关系，而且提供了查询每个客人点菜情况的方法。内蕴状态在这里代表了菜肴的种类，而外蕴状态就是每盘菜肴的点菜人。

A 让我们先来看看单纯享元模式的实现吧。

先看下抽象享元角色的定义：GoF对享元模式的描述是：运用共享技术有效地支持大量细粒度的对象。

Flyweight模式是构造型模式之一，它通过与其他类似对象共享数据来减小内存占用。也就是说在一个系统中如果有多个相同的对象，那么只共享一份就可 以了，不必每个都去实例化一个对象。在Flyweight模式中，由于要产生各种各样的对象，所以在Flyweight(享元)模式中常出现 Factory模式。Flyweight的内部状态是用来共享的,Flyweight factory负责维护一个对象存储池（Flyweight Pool）来存放内部状态的对象。为了调用方便，FlyweightFactory类一般使用Singleton模式实现。Flyweight模式是一个
提高程序效率和性能的模式,会大大加快程序的运行速度。
Flyweight模式的有效性很大程度上取决于如何使用它以及在何处使用它。当以下情况成立时使用Flyweight模式：

1 一个应用程序使用了大量的对象。

2 完全由于使用大量的对象，造成很大的存储开销。

3 对象的大多数状态都可以变为外部状态。

4 如果删除对象以外的状态那么可以用相对较少的共享对象取代很多组对象。

5 应用程序不依赖于对象标识。

其结构图如下所示：



比如说，一个咖啡店有几种口味的咖啡（拿铁、摩卡、卡布奇诺等等），如果这家店接到分订单要几十杯咖啡。那么显然咖啡的口味就可以设置成共享的，而不必为每一杯单独生成。代码实现如下：
import java.util.*;
public abstract class Order {

// 执行卖出动作

public abstract void sell();

}
public class FlavorOrder extends Order {

public String flavor;
// 获取咖啡口味

public FlavorOrder(String flavor) {

this.flavor = flavor;

}
@Override

public void sell() {

// TODO Auto-generated method stub

System.out.println("卖出一份" + flavor + "的咖啡。");

}

}
public class FlavorFactory {

private Map<String, Order> flavorPool = new HashMap<String, Order>();
// 静态工厂,负责生成订单对象

private static FlavorFactory flavorFactory = new FlavorFactory();
private FlavorFactory() {

}
public static FlavorFactory getInstance() {

return flavorFactory;

}
public Order getOrder(String flavor) {

Order order = null;
if (flavorPool.containsKey(flavor)) {// 如果此映射包含指定键的映射关系，则返回 true

order = flavorPool.get(flavor);
} else {

order = new FlavorOrder(flavor);

flavorPool.put(flavor, order);

}

return order;

}
public int getTotalFlavorsMade() {

return flavorPool.size();

}

}
public class Client {

// 客户下的订单

private static List<Order> orders = new ArrayList<Order>();
// 订单对象生成工厂

private static FlavorFactory flavorFactory;
// 增加订单

private static void takeOrders(String flavor) {

orders.add(flavorFactory.getOrder(flavor));

}
public static void main(String[] args) {

// 订单生成工厂

flavorFactory = FlavorFactory.getInstance();
// 增加订单

takeOrders("摩卡");

takeOrders("卡布奇诺");

takeOrders("香草星冰乐");

takeOrders("香草星冰乐");

takeOrders("拿铁");

takeOrders("卡布奇诺");

takeOrders("拿铁");

takeOrders("卡布奇诺");

takeOrders("摩卡");

takeOrders("香草星冰乐");

takeOrders("卡布奇诺");

takeOrders("摩卡");

takeOrders("香草星冰乐");

takeOrders("拿铁");

takeOrders("拿铁");
// 卖咖啡

for (Order order : orders) {

order.sell();

}
// 打印生成的订单java对象数量

System.out.println("\n客户一共买了 " + orders.size() + " 杯咖啡! ");
// 打印生成的订单java对象数量

System.out.println("共生成了 " + flavorFactory.getTotalFlavorsMade()

+ " 个 FlavorOrder java对象! ");

}

}
卖出一份摩卡的咖啡。

卖出一份卡布奇诺的咖啡。

卖出一份香草星冰乐的咖啡。

卖出一份香草星冰乐的咖啡。

卖出一份拿铁的咖啡。

卖出一份卡布奇诺的咖啡。

卖出一份拿铁的咖啡。

卖出一份卡布奇诺的咖啡。

卖出一份摩卡的咖啡。

卖出一份香草星冰乐的咖啡。

卖出一份卡布奇诺的咖啡。

卖出一份摩卡的咖啡。

卖出一份香草星冰乐的咖啡。

卖出一份拿铁的咖啡。

卖出一份拿铁的咖啡。
客户一共买了 15 杯咖啡!

共生成了 4 个 FlavorOrder java对象!
正如输入结果对比所示，把口味共享极大减少了对象数目，减小了内存消耗。
优缺点：

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

2）享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。
一、引子
让我们先来复习下java中String类型的特性：String类型的对象一旦被创造就不可改变；当两个String对象所包含的内容相同的时候，JVM只创建一个String对象对应这两个不同的对象引用。让我们来证实下着两个特性吧（如果你已经了解，请跳过直接阅读第二部分）。
先来验证下第二个特性：
public class TestPattern {
public static void main(String[] args){
String n = "I Love Java";
String m = "I Love Java";
System.out.println(n==m);
}
}
这段代码会告诉你n==m是true，这就说明了在JVM中n和m两个引用了同一个String对象（如果你还分不清== 和 equals的区别的话，请先确认）。
那么接着验证下第一个特性：
在系统输出之前加入一行代码“m = m + "hehe";”，这时候n==m结果为false，为什么刚才两个还是引用相同的对象，现在就不是了呢？原因就是在执行后添加语句时，m指向了一个新创建的String对象，而不是修改引用的对象。

呵呵，说着说着就差点跑了题，并不是每个String的特性都跟我们今天的主题有关的。

String类型的设计避免了在创建N多的String对象时产生的不必要的资源损耗，可以说是享元模式应用的范例，那么让我们带着对享元的一点模糊的认识开始，来看看怎么在自己的程序中正确的使用享元模式！
注：使用String类型请遵循《Effective Java》中的建议。
二、定义与分类
享元模式英文称为“Flyweight Pattern”，我非常感谢将Flyweight Pattern翻译成享元模式的那位强人，因为这个词将这个模式使用的方式明白得表示了出来；如果翻译成为羽量级模式或者蝇量级模式等等，虽然可以含蓄的表现出使用此模式达到的目的，但是还是没有抓住此模式的关键。
享元模式的定义为：采用一个共享来避免大量拥有相同内容对象的开销。这种开销中最常见、直观的就是内存的损耗。享元模式以共享的方式高效的支持大量的细粒度对象。
在名字和定义中都体现出了共享这一个核心概念，那么怎么来实现共享呢？要知道每个事物都是不同的，但是又有一定的共性，如果只有完全相同的事物才能共享，那么享元模式可以说就是不可行的；因此我们应该尽量将事物的共性共享，而又保留它的个性。为了做到这点，享元模式中区分了内蕴状态和外蕴状态。内蕴状态就是共性，外蕴状态就是个性了。

注：共享的对象必须是不可变的，不然一变则全变（如果有这种需求除外
内蕴状态存 储在享元内部，不会随环境的改变而有所不同，是可以共享的；外蕴状态是不可以共享的，它随环境的改变而改变的，因此外蕴状态是由客户端来保持（因为环境的 变化是由客户端引起的）。在每个具体的环境下，客户端将外蕴状态传递给享元，从而创建不同的对象出来。至于怎样来维护客户端保持的外蕴状态和享元内部保持 的内蕴状态的对应关系，你先不用担心这个问题，我们后面会涉及到的。
我们引用《Java与模式》中的分类，将享元模式分为：单纯享元模式和复合享元模式。在下一个小节里面我们将详细的讲解这两种享元模式。

三、结构
先从简单的入手，看看单纯享元模式的结构。
1) 抽象享元角色：为具体享元角色规定了必须实现的方法，而外蕴状态就是以参数的形式通过此方法传入。在Java中可以由抽象类、接口来担当。
2) 具体享元角色：实现抽象角色规定的方法。如果存在内蕴状态，就负责为内蕴状态提供存储空间。
3) 享元工厂角色：负责创建和管理享元角色。要想达到共享的目的，这个角色的实现是关键！
4) 客户端角色：维护对所有享元对象的引用，而且还需要存储对应的外蕴状态。

来用类图来形象地表示出它们的关系吧（对类图的了解可以参看我关于类图的blog）。



怎么咋看咋像简单工厂模式呢！没错，可以说结构型的单纯享元模式和创建型的简单工厂模式实现上非常相似，但是它的重点或者用意却和工厂模式截然不同。工厂模式的使用主要是为了使系统不依赖于实现得细节（见《深入浅出工厂模式》）；而在享元模式的主要目的如前面所述：采用共享技术来避免大量拥有相同内容对象的开销。正所谓“旧瓶装新酒”阿！

再来看看复合享元模式的结构。
1) 抽象享元角色：为具体享元角色规定了必须实现的方法，而外蕴状态就是以参数的形式通过此方法传入。在Java中可以由抽象类、接口来担当。
2) 具体享元角色：实现抽象角色规定的方法。如果存在内蕴状态，就负责为内蕴状态提供存储空间。
3) 复合享元角色：它所代表的对象是不可以共享的，并且可以分解成为多个单纯享元对象的组合。
4) 享元工厂角色：负责创建和管理享元角色。要想达到共享的目的，这个角色的实现是关键！
5) 客户端角色：维护对所有享元对象的引用，而且还需要存储对应的外蕴状态。
统比一下单纯享元对象和复合享元对象，里面只多出了一个复合享元角色，但是它的结构就发生了很大的变化。我们还是使用类图来表示下：



你 也许又纳闷了，这个也似曾相逢！单看左半部，和简单工厂模式类似；再看右半部，怎么这么像合成模式呢（请参看关于合成模式的文章或者期待我的《深入浅出合 成模式》）！合成模式用在此处就是为了将具体享元角色和复合享元角色同等对待和处理，通过将享元模式与合成模式组合在一起，可以确保复合享元中所包含的每 个单纯享元都具有相同的外蕴状态，而这些单纯享元的内蕴状态往往是不同的。

四、举例
这里就以去餐馆吃饭为例详细的说明下享元模式的使用方式。去菜馆点菜吃饭的过程大家一定都是轻车熟路了，这里就不赘述。在例子中我使用了一个list来存放外蕴状态和内蕴状态的对应关系，而且提供了查询每个客人点菜情况的方法。内蕴状态在这里代表了菜肴的种类，而外蕴状态就是每盘菜肴的点菜人。

A 让我们先来看看单纯享元模式的实现吧。

先看下抽象享元角色的定义：
interface Menu
{
//规定了实现类必须实现设置内外关系的方法
public void setPersonMenu(String person , List list);
//规定了实现类必须实现查找外蕴状态对应的内蕴状态的方法
public List findPersonMenu(String person, List list);
}
这便是具体享元角色了：
class PersonMenu implements Menu
{
private String dish ;
//在构造方法中给内蕴状态附值
public PersonMenu(String dish){
this.dish = dish ;
}
public synchronized void setPersonMenu(String person , List list)
{
list.add(person);
list.add(dish);
}
public List findPersonMenu(String person, List list)
{
List dishList = new ArrayList();
Iterator it = list.iterator();
while(it.hasNext())
{
if(person.equals((String)it.next()))
dishList.add(it.next());
}
return dishList ;
}
}
享元工厂角色，这可是关键所在，大家注意看！
class FlyweightFactory
{
private Map menuList = new HashMap();
private static FlyweightFactory factory = new FlyweightFactory();
//这里还使用了单例模式，来使工厂对象只产生一个工厂实例
private FlyweightFactory(){}
public static FlyweightFactory getInstance()
{
return factory ;
}
//这就是享元模式同工厂模式的不同所在！！
public synchronized Menu factory(String dish)
{
//判断如果内蕴状态已经存在就不再重新生成，而是使用原来的，否则就重新生成
if(menuList.containsKey(dish))
{
return (Menu)menuList.get(dish);
}else{
Menu menu = new PersonMenu(dish);
menuList.put(dish,menu);
return menu;
}
}
//来验证下是不是真的少产生了对象
public int getNumber()
{
return menuList.size();
}
}
我们使用客户程序来试验下吧。
class Client
{
private static FlyweightFactory factory ;
public static void main(String[] args)
{
List list1 = new ArrayList();
factory = FlyweightFactory.getInstance();
Menu list = factory.factory("尖椒土豆丝");
list.setPersonMenu("ai92",list1);
list = factory.factory("红烧肉");
list.setPersonMenu("ai92",list1);
list = factory.factory("地三鲜");
list.setPersonMenu("ai92",list1);
list = factory.factory("地三鲜");
list.setPersonMenu("ai92",list1);
list = factory.factory("红焖鲤鱼");
list.setPersonMenu("ai92",list1);
list = factory.factory("红烧肉");
list.setPersonMenu("ai921",list1);
list = factory.factory("红焖鲤鱼");
list.setPersonMenu("ai921",list1);
list = factory.factory("地三鲜");
list.setPersonMenu("ai921",list1);
System.out.println(factory.getNumber());

List list2 = list.findPersonMenu("ai921",list1);
Iterator it = list2.iterator();
while(it.hasNext())
{
System.out.println(" "+it.next());
}
}
}

这 样便使用单纯享元模式实现了这些功能，但是你是不是发现一个人点了好几样菜的时候是不是使用很不方便？而这种情况正好符合复合享元模式的使用条件：复合享 元中所包含的每个单纯享元都具有相同的外蕴状态，而这些单纯享元的内蕴状态往往是不同的。由于复合享元模式不能共享，所以不存在什么内外状态对应的问题。 所以在复合享元类中我们不用实现抽象享元对象中的方法，因此这里采用的是透明式的合成模式。

那么下面我就使用复合享元模式在上例的基础上来实现一下。

首先要实现一个复合享元角色：

class PersonMenuMuch implements Menu

{

private Map MenuList = new HashMap();

public PersonMenuMuch(){}

//增加一个新的单纯享元对象

public void add(String key , Menu menu)

{

MenuList.put(key , menu);

}

//两个无为的方法

public synchronized void setPersonMenu(String person , List list)

{ }

public List findPersonMenu(String person, List list)

{

List nothing = null ;

return nothing ;

}

}

在工厂方法中添加一个方法，实现重载。

public Menu factory(String[] dish)

{

PersonMenuMuch menu = new PersonMenuMuch();

String key = null ;

for(int i=0 ; i<dish.length ; i++)

{

key = dish[i];

menu.add(key , this.factory(key));//调用了单纯享元角色的工厂方法

}

return menu ;

}

也许我的例子举的不太恰当，但是基本上也能看出单纯享元模式和复合享元模式在实现上的特点，如果这个目的达到了那就忘了这个糟糕的例子吧（不要让它成了你深入理解享元模式的障碍），让我们来分析下这两种模式吧。

先从复杂度上来讲，复合享元模式显而易见是比单纯享元模式复杂的。

再从享元模式的关键——共享，来分析：复合享元模式在共享上面是没有达到预期的效果，可以说是没有起到共享的目的。虽然对于它内部包含的单纯享元角色来说还是能够起到共享的作用，但是复合享元角色中一个内蕴状态和对象使用了两个Map来保存，这肯定是不会节省什么空间和对象个数的。所以我认为复合享元模式是违背享元模式初衷的。因此我们应该尽量使用单纯享元模式。

在程序中你也许注意到，我对内蕴外蕴状态对应关系的保持是采用一个list表来做的，这仅仅是个举例，你完全可以采用各种能达到目的的方式来完成。这一点 也说明在享元模式中仅提供给我们怎么来吧一个对象的状态分开来达到共享，而对于关系的维护它是不关心的，也不是这个模式涉及的内容。

这样我就把享元模式使用一个例子详细的讲解了一下。如果还是不太明白的话请回味下前面的定义与结构。只有两者结合才能很好的体会到享元模式的用意。

五、使用优缺点
享元模式优点就在于它能够大幅度的降低内存中对象的数量；而为了做到这一步也带来了它的缺点：它使得系统逻辑复杂化，而且在一定程度上外蕴状态影响了系统的速度。
所以一定要切记使用享元模式的条件：
1) 系统中有大量的对象，他们使系统的效率降低。
2) 这些对象的状态可以分离出所需要的内外两部分。
外 蕴状态和内蕴状态的划分以及两者关系的对应也是非常值得重视的。只有将内外划分妥当才能使内蕴状态发挥它应有的作用；如果划分失误，在最糟糕的情况下系统 中的对象是一个也不会减少的！两者的对应关系的维护和查找也是要花费一定的空间（当然这个比起不使用共享对象要小得多）和时间的，可以说享元模式就是使用 时间来换取空间的。在Gof的书中是使用了B树来进行对应关系查找优化。

六、总结

也许你要长叹一声：这个享元模式未必太复杂了吧！这点是不得不承认的，也许由于它的复杂，实际应用也不是很多，这是我们更加无法看清他的真面目了。不过享 元模式并不是鸡肋，它的精髓——共享是对我们系统优化非常有好处的，而且这种思想已经别越来越多的应用，这应该就算是享元模式的应用了吧。如果你已经领会 到了享元模式的精髓，那么也就是掌握了享元模式了!

匆匆学完了享元模式，不知道理解上有没有纰漏，希望大家能指正出来，一起共同进步！其实我一直想使用一个实际系统中或者实践中的例子来讲解享元模式，可是毕竟自己的工作经验太少了！！于是想在网上找一些灵感来，可是狂搜一阵子也没有发现什么，于是就又落俗套的使用了一个比喻的例子。如果您对此深有体会的话，还烦请不吝赐教！！

Flyweight在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。是一种结构模式，处理类和对象之间的组合，避免大量拥有相同内容的小类的开销（入耗费内存），使大家共享一个类（元类）。

享元模式是一个提高程序效率和性能的模式，会大大加快程序的运行速度，应用场合很多：比如从一个数据库中读取一系列的字符串，这些字符串中有很多重复的，这时候就可以讲重复的字符转存贮在Flyweight池中。

又比如说一个文本系统，每个字母定义一个对象，大小写在一块一共定义52个对象。如果在一个1M的文本中有那么多的字母，如果每个字母都要定义一个对象的话内存占有量就太大了。如果每个字母都共享一个对象的话那就只用定义52个对象，用到的时候直接来拿就节省了很多资源。
public class Test {
public static void main(String[] args)

{ String a = "abc";

String b = "abc";
String c=“ab”+”c”;

System.out.println(a==b);
System.out.println(a==c); }

}

享元模式可以分成单纯享元模式和复合享元模式两种形式。
在单纯的享元模式中，所有的享元对象都是可以共享的。
在单纯享元模式中，所有的享元对象都是单纯享元对象，也就是说都是可以直接共享的。还有一种较为复杂的情况，将一些单纯享元使用合成模式加以复合，形成复合享元对象。这样的复合享元对象本身不能共享，但是它们可以分解成单纯享元对象，而后者则可以共享。

享元对象能做到共享的关键是区分内蕴状态(Internal State)和外蕴状态(External State)。 　　一个内蕴状态是存储在享元对象内部的，并且是不会随环境的改变而有所不同。因此，一个享元可以具有内蕴状态并可以共享。 　　一个外蕴状态是随环境的改变而改变的、不可以共享的。享元对象的外蕴状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外蕴状态不可以影响享元对象的内蕴状态，它们是相互独立的。

抽象享元角色：是所有具体享元角色的超类需要实现公共接口，可以通过这个导入外蕴状态。
具体享元角色：实现抽象香园角色的接口，并负责为内蕴状态提供空间，使得内蕴与周围的环境无关。
享元工厂角色：负责创建和管理享元角色。工厂必须保证里面的对象可以被系统适当的时候共享，当客户端对象需要调用一个共享对象的时候，工厂角色要去查看自己是否有这个对象，有就直接拿出去用，没有就立刻在创建一个。
客户端角色：需要维护一个对所有对象的引用，并且要自行存储所有享元对象的外蕴状态。



抽象享元角色：是所有具体享元角色的超类需要实现公共接口，可以通过这个导入外蕴状态。
具体享元角色：实现抽象香园角色的接口，并负责为内蕴状态提供空间，使得内蕴与周围的环境无关。
复合享元角色：不可以被共享但是可以分为很多可以被共享的单元。
享元工厂角色：负责创建和管理享元角色。工厂必须保证里面的对象可以被系统适当的时候共享，当客户端对象需要调用一个共享对象的时候，工厂角色要去查看自己是否有这个对象，有就直接拿出去用，没有就立刻在创建一个。
客户端角色：需要维护一个对所有对象的引用，并且要自行存储所有享元对象的外蕴状态。



享元模式的优缺点 　　享元模式的优点在于它大幅度地降低内存中对象的数量。但是，它做到这一点所付出的代价也是很高的： 　　●　　享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。 　　●　　享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。

享元模式以共享的方式高效地支持大量的细粒度对象。
在面向对象的程序设计语言看来，一切事务都被描述成对象（Object）。对象拥有状态（属性）和行为（方法），我们将具有相同行为的对象抽象为类（Class），类可以被看作只保留行为的对象模板，类可以在运行时被重新赋予状态数据从而形成了对象。
在运行时，对象占用一定的内存空间用来存储状态数据。如果不作特殊的处理，尽管是由同一个类生成的两个对象，而且这两个对象的的状态数据完 全相同，但在内存中还是会占用两份空间，这样的情况对于程序的功能也许并没有影响，但如果把状态相同的同一类对象在内存中进行合并，必然会大大减少存储空 间的浪费。
举一个现实中的例子，某淘宝店经营一款畅销女式皮鞋，每天需要处理大量的订单信息，在订单中需要注明客户购买的皮鞋信息，我们将皮鞋产品抽象出来：

class Shoe{

String color;//颜色

int size;//尺寸

String position;//库存位置

public String getColor() {

return color;

}

public void setColor(String color) {

this.color = color;

}

public int getSize() {

return size;

}

public void setSize(int size) {

this.size = size;

}

public String getPosition() {

return position;

}

public void setPosition(String position) {

this.position = position;

}

}

正如上面的代码所描述，皮鞋分为颜色、尺寸和库存位置三项状态数据。其中颜色和尺寸为皮鞋的自然状态，我们称之为对象内部状态，这些状态数据只与对象本身 有关，不随外界环境的改变而发生变化。再来看库存位置，我们将这个状态称为对象的外部状态，外部状态与对象本身无必然关系，外部状态总是因为外界环境的改 变而变化，也就是说外部状态是由外界环境来决定的。在本例中，皮鞋今天放在A仓库，明天可能放在B仓库，但无论存放在哪个仓库，同一只皮鞋就是同一只皮 鞋，它的颜色和尺寸不会随着存放位置的不同而发生变化。
享元模式的核心思想就是将内部状态相同的对象在存储时进行缓存。也就是说同一颜色同一尺寸的皮鞋，我们在内存中只保留一份实例，在访问对象时，我们访问的其实是对象缓存的版本，而不是每次都重新生成对象。

享元模式仍然允许对象具有外部属性，由于我们访问的始终是对象缓存的版本，所以我们在使用对象前，必须将外部状态重新注入对象。由于享元模式禁止生成新的对象，所以在使用享元模式时，通常伴随着工厂方法的应用。我们来看下面的例子：

class ShoeFactory {

Collection<Shoe> shoes = new ArrayList<Shoe>();

Shoe getSheo(String color, int size, String position) {

//首先在缓存中查找对象

for (Shoe shoe : shoes) {

if (shoe.getColor() == color && shoe.getSize() == size) {

//在缓存中命中对象后还原对象的外部属性

shoe.setPosition(position);

return shoe;

}

}

//如果缓存未命中则新建对象并加入缓存

Shoe shoe = new Shoe();

shoe.setColor(color);

shoe.setSize(size);

shoe.setPosition(position);

shoes.add(shoe);

return shoe;

}

}

通过ShoeFactory工厂，我们每次拿到的皮鞋都是缓存的版本，如果缓存中没有我们需要的对象，则新创建对象然后加入缓存中。注意上例中对象的外部属性position是如何注回对象的。
当我们在自己的业务场景中应用享元模式时，一定要注意分清对象的内部状态和外部状态，享元模式强调缓存的版本只能包含对象的内部状态。
事实上，Java中的String和Integer类都是享元模式的应用的例子，String类内部对所有的字符串对象进行缓存，相同的字符串在内存中只会保留一个版本。类似的，Integer类在内部对小于255的整数也进行了缓存。
享元模式在企业级架构设计中应用的例子比比皆是，现代大型企业级应用中不可或缺的缓存体系也正是在享元模式的基础上逐步完善和发展起来的。