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

2019独角兽企业重金招聘Python工程师标准>>>

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

        为什么需要这样子呢，我们平时开发关注的一般都是搬砖写代码，只要把它实现了就好，老板想要的实现结果，过程它不关注，这个对于如果是初创的app或者工程来说，好维护，但是如果动辄几十万行代码的大工程来说，是不就会出问题了呢。由于个人设计经验有限，引用有个做游戏的小伙伴的说法个人觉得挺生动的，比如我游戏中，有土地、草、树木、石头、房子、木板等，他们都有具体的特征和不同的地方，如果存在10对象实体，了而对象的提供了5个接口函数，也就是，读写操作，在程序中出现了几十次，这时，如果不要这个对象了，换成其他，那你是不是要改几十处地方，这个时候如果需要修改，那就动辄几十上百个地方了，这个时候我们想起了一个工厂模式来进行改造。new的对象你不用关心它里面的具体实现，比如如果你用new出来的对象，可能带有参数或者不带参数，如果参数都改动的话，那几十个new的地方是不会搞得你的很淡疼。所以这个也是我个人理解为什么使用工厂模式的理由之一。工厂模式其实还有个很重要的点，就是生产的产品可以拥有共同的特性，比如这儿说土地、草、树木等，我们是不要把它显示出来，虽然本人没做过游戏，但是我们想象一个过程，他们在各自的实现类中比如可能有1、 图片（设计给的图片代表花、草、树木）2、动作（比如是否会随着风飘动的幅度，也就是动画） 3、绘制显示 （给予的图片+动作绘制显示），这儿说到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内聚能力降低，程序逐步庞大必然会越发明显，真所谓牵一发动全身，小程序确实是很难看出问题所在。

转载于:https://my.oschina.net/u/3318187/blog/2222456