javascript设计模式学习之十二——享元模式

一、享元模式的定义及使用场景

享元模式是为了解决性能问题而诞生的设计模式，这和大部分设计模式为了提高程序复用性的原因不太一样，如果系统中因为创建了大量类似对象而导致内存占用过高，享元模式就非常有用了。

享元模式的关键是区分内部状态和外部状态，剥离了外部状态的对象成为共享对象。有多少种内部状态的组合，系统中便最多存在多少个共享对象。而外部状态存在于共享对象的外部，在必要时被传入共享对象来组成一个完整的对象。一般情况下，以下情况发生时，可以使用享元模式：

1）一个程序使用了大量的类似对象；

2）由于使用了大量对象，造成了很大的内存开销；

3）对象的大部分状态都可以变为外部状态；

剥离出对象的外部状态后，可以用相对较少的共享对象取代大量对象。

二、享元模式使用案例

享元模式中通常存在这样的角色：

1）对象工厂：当共享对象真正被需要时，才从工厂中生产出来；

2）管理器，使用管理器来记录对象相关的外部状态，使得这些外部状态通过某个钩子和共享对象联系起来。

以文件上传为案例进行分析，web上传一般支持多种方式，如浏览器插件，flash和表单上传等。为了简化例子，假设只有插件和Flash两种方式，无论是插件上传，还是Flash上传，原理都一样，当用户选择了文件之后，插件和Flash都会通知调用window下的一个全局Javascript函数，它的名字是startUpload,用户选择的文件列表被组合成一个数组files塞进该函数的参数列表中，代码如下：

    var id=;
    window.startUpload=function(uploadType,files){
        for(var i=,len=files.length;i<len;i++){
            var curFile=files[i];
            var uploadObj=new Upload(uploadType,curFile.fileName,curFile.fileSize);
            uploadObj.init(id++);
        }
    };

可见，如果同时选择2000个文件，就会在程序中同时new了2000个upload对象，结果可想而知，浏览器很可能进入假死状态。

对上面的情况使用享元模式进行改造，uploadType作为内部状态，其他外部状态可以剥离出来。

//享元模式学习
    var Upload=function(uploadType){
        this.uploadType=uploadType;
    };
    Upload.prototype.delFile=function(id){
        uploadManager.setExternalState(id,this);
        if(this.fileSize<){
            return this.dom.parentNode.removeChild(this.dom);
        }
        if(window.confirm('确定要删除文件吗'+this.fileName)){
            return this.dom.parentNode.removeChild(this.dom);
        }
    };

    //使用对象工厂进行对象实例化，使得只在需要的时候才产生对象
    var uploadFactory=(function(){
        var uploadPool={};
        return {
            create:function(uploadType){
                if(uploadPool[uploadType]){
                    return uploadPool[uploadType];
                }
                return uploadPool[uploadType]=new Upload(uploadType);
            },
        };
    })();

    //使用管理器封装外部状态

    var uploadManager=(function(){
        //保存所有upload对象的外部状态
        var uploadDatabase={};
        return {
            add:function(id,uploadType,fileName,fileSize){
                var uploadObj=uploadFactory.create(uploadType);
                var dom=document.createElement('div');
                dom.innerHTML='文件名称'+fileName+',文件大小'+fileSize+'<button class="delFile">删除</button>';
                dom.querySelector('.delFile').onclick=function(){
                    uploadObj.delFile(id);
                };

                uploadDatabase[id]={
                    fileName:fileName,
                    fileSize:fileSize,
                    dom:dom
                };
                return uploadObj;
            },

            setExternalState:function(id,obj){
                var temp=uploadDatabase[id];
                for(var key in temp){
                    obj[key]=temp[key];
                }
            };
        };
    })();

    //此时触发上传的函数变成
    var id=;
    window.startUpload=function(uploadType,files){
        for(var i=,len=files.length;i<len;i++){
            var curFile=files[i];
            var uploadObj=uploadManager.add(++id,uploadType,curFile.fileName,curFile.fileSize);

        }
    };

可见，此时，不论上传多少文件，都仅需要创建两个uploadObj对象即可，系统性能得到了较大提升。

三、享元模式的进一步讨论

1）没有内部状态的享元模式

试想，如果系统中只有Flash或者插件一种上传方式，那么产生对象的工厂就变成了单例模式

    //如果没有内部状态，则生产对象的工厂实质上就变成了单例工厂，此时共享对象没有内部状态的区分，不过还是有剥离外部状态的过程，依旧倾向于称之为享元模式
    var uploadFactory=(function(){
        var uploadObj;
        return{
            create:function(){
                if(uploadObj){
                    return uploadObj;
                }
                    return uploadObj=new Upload();
                }
            }

    })();

2）没有外部对象的享元模式

java,c#中的字符串，对象池（http连接池，数据库连接池）都属于这种情况，在web前端中，对象池使用最多的是dom有关的操作。对象池和享元模式的思想有点像，但因为没有剥离外部对象的过程，一般不称之为享元模式。下面是一个通用的对象池代码实现：

var objectPoolFactory=function(createObjFn){
        var objPool=[];
        return{
            create:function(){
                var obj=objPool.length==?createObjFn.apply(this,arguments):objPool.shift();
                return obj;
            },
            recover:function(obj){
                objPool.push(obj);
            },
        };
    }