多例模式（升级单例模式）

纠结了很久，要不要写设计模式的博客，顾及的有两点：一来自己深度不够怕班门弄斧，二来怕说错了误导读者。不过有一个大牛说过，学习过的东西自己思考后写出来是一个更好的学习提高过程，不要因为自己浅薄而放弃这个学习的机会。所以我来了，带来了我的一些不成熟的想法。

这个系列我不会说得太虚太高端，主要是在工作中遇到的一些场景和我用来处理这些问题的方法。

需求描述：将原有的存储显示拆分为内置和外置存储信息的分别显示，并支持其他页面的详情显示（比如显示文件列表）。

前置条件：已有进行对分区存储情况进行计算的类Measurer。

脑力活动：看到上面的需求和前置条件，很容易想到几个关键点：

                    内置和外置存储需要计算的内容是几乎一致的；

                    两者的计算过程也是一致的，只是管理的分区不一样；

                    支持两部分的计算数据在其他页面共享。

脑子一拍，这不就是逼我用多例模式的节奏么，之前为了减少创建Measurer的实例节省内存，并建立多页面之间的共享资源已经将它设计为单例了（这两点也是单例模式的主要应用特征），现在需要两个可以同时胜任这项工作的实例，理所应当的可以将其扩展为多例，并且是又上限的多例模式。（PS上限为1的多例就是单例）

多例模式与单例模式一样，类图都比较简单：同样的类的实例需要类自己进行创建和管理，并提供对外获取的接口。

                     

特别需要说明的只是实例的创建方法，类似的，多例模式的实例创建方式也分为饿汉式、懒汉式，当然这都是为了解决多线程访问的问题。我个人比较推崇饿汉式也更安全一些。

public class Measurer{

    private static Measurer inM = new Measurer();

    private static Measurer exM = new Measurer();

    private Measurer( ){
    }

    public static Measurer getInstance(int whichOne){

        if(whichOne == 1){
             return inM;
        }else{
             return exM;
        }
    }
}

单例模式和多例模式都是一个static的实例，所以在Android中有一种情况需要特别注意就是这个类中需要使用Context的情况，最好不要将其设计为成员变量，让其作为方法的参数是一个更好的选择。

当然了多例模式还有很多其他的使用场景，以上我说的只是一个从单例到多例的典型的改造情景。

普遍的，用服务和客户端来解释就是，服务系统需要创建多个实例来满足多个客户请求的情景。这些请求可以是同时也可以是不同时的，大多数情况下这些请求之间是没有什么关联的。还有一种特别的，在大量并发请求的情况下，系统为了快速响应求情并保持总的开销稳定，会有一个有上限多例模式，也就是池的概念。（线程池、连接池等等）