如果我们要存储一个树一样的数据结构，直觉来说我们会这么写
但是实际上我们会发现，哪怕森林里有千千万万的树，它们大多数长得一模一样。 它们使用了相同的网格和纹理。 这意味着这些树的实例的大部分字段是一样的。
那么我们就可以将树共有的数据拿出来分离到另一个类中：
我们只需要一个TreeModel实例化的对象就好了，剩下的树只需要保存一个TreeModel的指针，就可以很快的找到这个对象
类似于这样
为了减少需要推送到GPU的数据量，我们想把共享的数据——TreeModel——只发送一次。 然后，我们分别发送每个树独特的数据——位置，颜色，大小。 最后，我们告诉GPU，“使用同一模型渲染每个实例”。
在这些API中，你需要提供两部分数据流。 第一部分是一块需要渲染多次的共同数据——在例子中是树的网格和纹理。 第二部分是实例的列表以及绘制第一部分时需要使用的参数。 然后调用一次渲染，绘制整个森林。
这就是享元模式，实际上我认为享元模式没有什么好说的东西，所以这里的大部分内容我都是直接照搬原著的。
享元模式的使用场合
当系统中某个对象类型的实例较多的时候。
由于使用了大量的对象，造成了很大的存储开销。
在系统设计中，对象实例进行分类后，发现真正有区别的分类很少的时候。
如果享元模式与对象池联动，可以进一步减少内存的开销
原文链接：
享元模式 · Design Patterns Revisited · 游戏设计模式 (tkchu.me)
