通过这种方式进行事件绑定，可以减少事件处理程序的数量，这种方式叫做事件委托，也是运用了享元模式的原理。事件处理程序是公用的内在部分，每个菜单项各自的文本就是外在部分。我们简单说下事件委托的原理：点击菜单项，事件会从li元素冒泡到ul元素，我们绑定事件到ul上，实际上就绑定了一个事件，然后通过事件参数event里面的target来判断点击的具体是哪一个元素，比如低级第一个li元素，event.target就是li，这样就能拿到具体的点击元素了，就可以根据不同元素进行不同的处理。
总结
享元模式是一种优化程序性能的手段，通过共享公用数据来减少对象数量以达到优化程序的手段。享元模式适用于拥有大量类似对象并且对性能有要求的场景。因为享元模式需要分离内部和外部数据，增加了程序的逻辑复杂性，建议对性能有要求的时候才使用享元模式。
享元模式之利：
可以把网页的资源符合降低几个数量级。即使享元模式的应用无法将实例的个数削减到一个，你仍能够从中获益不少。
这种节省不需要大量修改原有代码。在创建了管理器、工厂和享元之后，就需要对代码进行的修改只不过是从直接实例化目标类改为调用管理器对象的某个方法。
享元模式之弊：
如果把它用在不必要的地方，其结果反而有损代码的运行效率。这种模式在优化代码的同时，也提高了其复杂程度，这会给调试和维护造成困难。
它之所以会妨碍调试，是因为现在可能出错的地方变成了三个：管理器、工厂和享元。
这种优化也会使维护变得更加困难。现在你面对的不是由封装着数据的对象构成的清晰架构，而是一堆又碎又乱的东西。其中的数据至少分两处保存。最好注释标明内在数据和外在数据。
只有在必要的时候才应该进行这种优化。必须在运行效率和可维护性之间进行权衡。如果拿不准是否需要使用享元模式，那么你很可能并不需要它。享元模式适合的是系统资源已经用得差不多而且明显需要进行某种优化这样一类场合。
这种模式对Javascript程序员特别有用，因为它可以用来减少网页上所要使用的DOM元素的数量，要知道这些元素需要耗费许多内存。结合使用这种模式与组合模式等组织型可以开发出功能丰富的复杂Web应用系统，它们可以平稳的运行在任何现代Javascript环境中。
享元模式的适用场合：
网页中必须使用了大量资源密集型对象。如果只会用到少许这类对象，这种优化并不划算。
对象中所保存的数据至少有一部分能被转化为外在数据。此外，将这些数据存储在对象外部所占用的资源应该相对较少，否则这种做法对于性能的提示实际上毫无意义。那种大量包含基础性代码和HTML内容的对象可能比较适合这种优化。
将外在数据分离出去后，独一无二的对象的数目相对较少。
您可能感兴趣的文章: