试想有一个程序员的类，属性是程序员的“技能”，方法就是coding()， 客户想要一个什么系统就去招一个可以开发这个系统(new)一个程序员，让他去coding，返回的就是自己想要的系统了。当然每招一个开发，项目结束再开掉一个开发，当然成本都是不容小觑的（同样的JVM每次创建和GC对象也都是有成本的，至于说为什么GC有成本，可以之后写文章再聊）
公司为了节约成本自然有很多的方式，有时候公司通常不会为了一个系统就去招一个程序员，通常的做法是看看公司内部是否有能干这个系统的这类型的程序员（比如对应的后端开发、前端开发），实际上一个类型的开发是可以接不同的需求的，如果已经有这个类型的程序员，直接拿来用就可以了，可以很大程度的节约成本，这就是享元模式。
说回享元模式（flyweight），也叫轻量级模式，从名称理解上来看就是共享元件（也就是共享实例）以达到尽可能的轻量。 从这个角度来看享元模式需要有两个核心的功能：一是提取变化与不变的部分（外部与内部状态），而是通过工厂管理不变的实例，通过参数传递变化的部分。
为此，享元模式通常包含（类比下图的架构）：
- 一个接口定义标准（ 比如程序员必须能coding）（Flyweight）
- 多种可复用的实现（ 前端、后端、java、python的coding的实现）(ConcreteFlyweight) （这里需要注意享元模式与对象池的区别）
- 一个工厂类，根据需求类型返回对应的实例 （根据系统类型 返回不同类型的程序员）(FlyweightFactoy)
- 同时，享元模式设计的核心在于剥离变化与不变，同一个类型的程序员的技能通常不变，变化的是需求，从而实现对象复用。(operation方法参数)
下面就是享元模式的结构图：
