再谈内部状态和外部状态-算法分析与设计---micheal t.goodrich roberto tamassia

12.5享元模式的适用性享元模式是一种很好的性能优化方案，但它也会带来一些复杂性的问题，从前面两组代码的比较可以看到，使用了享元模式之后，我们需要分别多维护一个factory对象和一个manager对象，在大部分不必要使用享元模式的环境下，这些开销是可以避免的。享元模式带来的好处很大程度上取决于如何使用以及何时使用，一般来说，以下情况发生时便可以使用享元模式。 一个程序中使用了大量的相似对象。 由于使用了大量对象，造成很大的内存开销。 对象的大多数状态都可以变为外部状态。 剥离出对象的外部状态之后，可以用相对较少的共享对象取代大量对象。可以看到，文件上传的例子完全符合这四点。 12.6再谈内部状态和外部状态如果顺利的话，通过前面的例子我们已经了解了内部状态和外部状态的概念以及享元模式的工作原理。我们知道，实现享元模式的关键是把内部状态和外部状态分离开来。有多少种内部状态的组合，系统中便多存在多少个共享对象，而外部状态储存在共享对象的外部，在必要时被传入共享对象来组装成一个完整的对象。现在来考虑两种极端的情况，即对象没有外部状态和没有内部状态的时候。 12.6.1没有内部状态的享元在文件上传的例子中，我们分别进行过插件调用和Flash调用，即startUpload( 'plugin', [] )和startUpload( flash, [] )，导致程序中创建了内部状态不同的两个共享对象。也许你会奇怪，在文件上传程序里，一般都会提前通过特性检测来选择一种上传方式，如果浏览器支持插件就用插件上传，如果不支持插件，就用Flash上传。那么，什么情况下既需要插件上传又需要Flash上传呢？实际上这个需求是存在的，很多网盘都提供了极速上传（控件）与普通上传（Flash）两种模式，如果极速上传不好使（可能是没有安装控件或者控件损坏），用户还可以随时切换到普通上传模式，所以这里确实是需要同时存在两个不同的upload共享对象。但不是每个网站都必须做得如此复杂，很多小一些的网站就只支持单一的上传方式。假设我图灵社区会员轩辕专享尊重版权