这个社会，想要挣钱，搞产业啊什么的，都需要像非诚勿扰那个海龟女大学老师讲的，那个产品必须是可复制的。像中国传统的剪纸啊，什么艺术啊之类的，就谈不起来产业。程序里面可不一样，程序里如果生产大量一摸一样的东西，那简直就是浪费啊。不仅浪费了空间，而且你要知道创建一个对象的开销有多大。诸如此类的问题，前人们已经帮我们总结了一种设计模式------享元模式。
在未接触享元模式之前，我自己常使用的一种方法是定义一个HashMap，将已经有的对象保存到hashMap中，下次再要使用对象时，看看这个hashmap中有没有，如果有则直接返回包含的对象，如果还没有则生成一个对象，再将这个对象保存到hashmap中。举个安卓的例子，一个应用程序在使用系统的contact的时候，获得联系人的头像。众所周知，bitmap对象在安卓系统中是个“胖”子，使用不当则会产生bitmap size exceeds VM budget，oh fuck,这种问题实在让人头疼。此时我建立的Hashmap是这样的HashMap<URI,Bitmap>。
我认为享元模式的原理跟这个差不多，但是别人都叫“模式”了，就要有一定的“通用性”，或者“专业性”。下面通过一个场景来类比一下享元模式中各种角色的职责，下面这个是纯种享员模式的UML类图。
假设我们去KFC，KFC里面有服务生，生产汉堡可乐的员工，菜单，买到的食物。分别对应上图的Client，FlyweightFactory,Flyweight,ConcreteFlyweight 。享元模式的原理就是，服务生在接受你点的order之后，对后面喊一声“草莓圣代”or “鸡肉汉堡”，后面生产的员工一听我“草莓圣代”早就生产过了直接扔过去了，“鸡肉汉堡”还没生产，那就生产一份，搞完了，下次有谁再要“鸡肉汉堡”，就直接扔过去了，FlyweightFactory已经对生产过的对象保存了一份。
这个是最简单的。。。。