对于设计模式最近观感的浅薄理解

      最近比较多翻阅设计模式，设计模式平时工做中，咱们可能会常常见到有，好比单例模式、观察者模式、模板模式，构建者模式，像好比以前使用的线程池内部使用的命令模式等，看的模式越多，愈加发现其实就一点： 面向接口编程 或者 抽象编程。

        为何须要这样子呢，咱们平时开发关注的通常都是搬砖写代码，只要把它实现了就好，老板想要的实现结果，过程它不关注，这个对于若是是初创的app或者工程来讲，好维护，可是若是动辄几十万行代码的大工程来讲，是不就会出问题了呢。因为我的设计经验有限，引用有个作游戏的小伙伴的说法我的以为挺生动的，好比我游戏中，有土地、草、树木、石头、房子、木板等，他们都有具体的特征和不一样的地方，若是存在10对象实体，了而对象的提供了5个接口函数，也就是，读写操做，在程序中出现了几十次，这时，若是不要这个对象了，换成其余，那你是否是要改几十处地方，这个时候若是须要修改，那就动辄几十上百个地方了，这个时候咱们想起了一个工厂模式来进行改造。new的对象你不用关心它里面的具体实现，好比若是你用new出来的对象，可能带有参数或者不带参数，若是参数都改动的话，那几十个new的地方是不会搞得你的很淡疼。因此这个也是我我的理解为何使用工厂模式的理由之一。工厂模式其实还有个很重要的点，就是生产的产品能够拥有共同的特性，好比这儿说土地、草、树木等，咱们是不要把它显示出来，虽然本人没作过游戏，可是咱们想象一个过程，他们在各自的实现类中好比可能有一、 图片（设计给的图片表明花、草、树木）二、动做（好比是否会随着风飘动的幅度，也就是动画） 三、绘制显示 （给予的图片+动做绘制显示），这儿说到3个方法咱们能够抽象出这些物件的特有属性，能够抽象出产品的公共接口，给予外部调用，而系统其它调用者不须要考虑它的内部具体实现。

      再说说我的理解之单例模式， 我会想真的为何我要使用单例模式，先不去教科书上说的，最直观一点是，它直接判断对象是否为空，只new一个实例能够重复使用，什么样场景咱们会用到单例，咱们android编程的小伙伴都知道，Http请求类、ImageLoader的调用基本都是会考虑用到单例模式，为何呢，一开始我也是有点茫然，后来想到一点是，不少对象都要用到它而不想要不断new对象形成资源浪费。若是回到现实中，我的想到好比一个部门的秘书，一个部门的秘书是不须要基本跟全部人都要大量的打交道处理一些事情，公司会不会给你一我的派一我的秘书给你去处理事情呢，这个不会吧，由于要成本啊，回到单例的话，这儿只是作个假设部门秘书通常一个就够了，假设秘书是一个对象的话，咱们就只new一个，是不和使用单例模式有点像，就是不要浪费资源。而从计算机角度来看，就是节省咱们硬件资源的开支，这是其一，其二还有个点是，内部的实现咱们对它作封装，不用管底层的实现。

       而像ImageLoader的实现也是使用到了单例模式，说到ImageLoader，它底层的实现算比较复杂的，比较多使用了构建者模式，就好比ImageLoader的建立其实咱们须要对ImageLoader的一个配置类作定性的初始化，若是这儿不使用单例模式，处处进行new的话，咱们处处会用到ImageLoaderConfiguration配置这个实例来建立ImageLoader，先不考虑资源浪费，就单代码的冗余度和维护度来看，挺难受的。ImageLoaderConfiguration使用的建立者模式的一个亮点是，它能够承载配置不少参数，而不对外暴露里面底层的实现方法，好比builder咱们能够配置它使用什么样的缓存，什么样的加载图片，网络加载失败后的图片、缓存的大小，缓存的图片文件名称加密方法，使用哪一种缓存机制，是fifo仍是lifo等，线程的优先级别（这儿我的有点盲点），各类类型参数大量配置而不暴露给ImageLoader，Imageloader是须要调用ImageLoaderConfiguration在中间去进行实现整个图片加载的过程，构建者的亮点我的理解就是在这儿。若是在认真看咱们的okhttp也是使用了有构建者模式，builder以后设置链接的超时时间，什么请求方式等，是否能够缓存，想象下咱们使用ImageLoader或Okhttp无非都是请求一个资源，这个是惟一的核心，可是若是在前面new了一大堆的对象A、B、C各类ImageLoader或OkHttp须要使用的配置参数，看起来这个代码是不很冗余，并且每次都这样作，是不很难维护呢？

    再谈起咱们常用的EventBus，EventBus使用了发布者/订阅者模式，或者说观察者模式，我先还原一个须要使用的场景，好比我有A、B、C、D等，我有个消息中心须要对A、B、C、D等进行发布消息，我怎么发送到给它们呢。观察者模式就是为了解决这个问题的，首先咱们能够对A、B、C等进行注册，实际上是把它们的实例加入咱们的一个列队集合中，这儿咱们最好使用一个线程安全的集合，避免同步的问题。等咱们须要发布消息的时候，咱们发布的消息会带着一个对象的东西（是不是主线程），咱们去遍历他们，使用咱们java的反射，而后获得相关的带有@Subscribe的注解的方法并获取到注解的内含有是不是主线程仍是后台线程的值，而后去在对应的线程去作相应的操做。

     设计模式本质我的理解是面向接口或者抽象类来作个抽象层，达到一个解耦的过程，让代码可以更好的维护。 稍微看多点代码，和本身翻阅有些资料书上来看，咱们在设计代码的时候，每每通常不想要被暴露的变量或者方法都使用protected或者private，想被继承的使用protected。这儿说的属于我的肤浅看法，总之是要达到对外界一种隔离的原则，想要暴露给外部的尽可能使用接口来进行。

        之前我的也是常常喜欢使用public 能够达到直接使用的过程，这儿其实会形成自身业务的暴露。 如A类有成员a,而程序须要对a数据改变，而你提供一惯的个B类能够访问a成员的getter接口，B类在其自身对a修改，看上去没什么，实际上，就是类耦合，对a的修改是类A的职务，因为习提供getter，致使了，在写类B的时候错误地添加了修改业务，使类A内聚能力下降，程序逐步庞大必然会愈加明显，真所谓牵一发动全身，小程序确实是很难看出问题所在。