安卓中的设计模式举例

在讲设计模式前，先通过讲故事复习一遍

面向对象设计六原则

• 单一职责原则,SRP(Single Responsibility Principle)
• 开放-关闭原则,OCP(Open-Close Principle)
• 里氏替换原则,LSP(Liskov Substitution Principle)
• 接口隔离原则,ISP(Interface Segregation Principle)
• 依赖倒置原则,DIP(Dependence Inversion Principle)
• 最少知识原则,LKP(Least Knowledge Principle),又称迪米特法则,LOD(Law Of Demeter)

故事来自《Android源码设计模式解析与实战》，我压缩了一下。这是本很好的书，把技术串进了故事里，叙述角度很有创意。

小民写一个图片加载库ImageLoader
第一版只用一个类实现图片加载功能，并且能通过内存缓存图片。
业务都包含在一个类里导致代码不易维护和扩展。
所以在做第二版时依据SOLID原则和迪米特原则重构项目

1.1 单一职责

划分职责，对代码进行模块化和封装，使得类结构清晰。

依照这个原则，ImageLoader分成了ImageLoader类和ImageCache类
前者是图片加载类，后者是图片缓存类。这样实现了一定程度的解耦。过了一段时间小民想优化图片缓存，比如加入SD卡缓存，让用户指定缓存位置等。但发现每次优化图片缓存，都需要改动ImageCache类。而既然ImageLoader中引用的ImageCache类，那么ImageCache类新增了一种特性，必然需要ImageLoader类也增加或者修改代码才能使用这种特性。
这样我们就进入下一个原则。

1.2 开闭原则

对扩展开放，对修改封闭。当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码。实现开闭原则的重要手段是通过抽象。

所以小民决定在ImageLoader中引用的ImageCache类改成ImageCache接口。
分别实现MemoryCache， DiskCache，DoubleCache来表示在内存中缓存，在SD卡中缓存，以及两者结合的双缓存。

ImageLoader UML 图

这里写图片描述

这样只要接口的定义没变，ImageLoader就不需要修改，如果想增加新的缓存方式，只需要写一个新的类实现ImageCache接口，而且这样客户端也可以传入自己实现的缓存类。
这样的实现也符合里氏替换原则和依赖倒置原则。

1.3 里氏替换原则

所有引用基类的地方都能够透明的使用其子类的对象。透明是指不需要关心子类的实现，只要像使用父类一样使用子类即可。

当我们使用不同的ImageCache实现类时，ImageLoader不需要实现任何改动。

1.4 依赖倒置原则

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生。

ImageLoader原来引用的是ImageCache类，小民改成了ImageCache接口，这样ImageLoader就只依赖于抽象而不依赖具体的实现。

1.5 接口隔离原则

客户端不应该依赖它不需要的接口，依赖应最小化。

比如我们的ImageCache接口只定义getCache 和 putCache两个方法。依照接口隔离原则能降低类之类的耦合。

1.6 迪米特原则

一个对象应该对其他对象有最少的了解。

比如小民最先采用wharton的DiskLruCache实现DiskCache，后来替换成了自己实现的SD卡缓存。但这些对客户端都没有影响，因为替换是在DiskLruCache内部完成的，客户端只知道ImageCache的get 和 set 接口。

可以看出，遵循SOLID原则最重要的途径是抽象 ，或者说面向接口编程

以上六原则可以作为判断一个设计模式是否良好的标准。
设计模式是什么？
是对软件设计中普遍存在的各种问题，所提出的可复用的解决思路。

设计模式的分类

创建型模式 Creation

结构模式 Structure

行为模式 Behavior

创建型模式

抽象了对象实例化过程

• 单例
  Application (每个程序有唯一的Application类，它的生命周期即此程序的生命周期)
  context.getSystemService(Context.LAYOUT_INFLATER_SERVICE)
• 工厂方法
  context.getSystemService(Context.LAYOUT_INFLATER_SERVICE)
• **简单工厂 **
  BitmapFactory.decodeFile(String path, Options opts)
• 抽象工厂
  MediaPlayerFactory的实现类StagefrightPlayer NuPlayerFactory SonivoxPlayerFactory TestPlayerFactory 分别生成不同的MediaPlayerBase
• 建造者 Builder
  AlertDialog.Builder
• 原型Prototype
  用于在组件之间传递数据的Intent

结构模式

描述如何将对象结合在一起形成更大的结构

• 适配器
  ListView 和 RecyclerView 的 Adapter（不同的view和不同的数据源，只要实现Adapter的规范，即可交互）
• 桥接
  Window 与 WindowManager
• 组合
  ViewGroup(各种炫酷的View =ViewGroupA+ViewGroupB+ViewC ViewGroupA=View+View+View )
• 装饰器
  ContextImpl和ContextWrapper
• 享元
  查询语句的编译结果 SQLiteCompiledSql
• 代理
  ActivityManagerProxy代理了ActivityManagerService的startActivity等功能
• 外观
  Media FrameWork（多媒体框架的实现需要多个底层library的协同工作，但多媒体开发者只需要熟悉android.media.MediaPlayer类，它已经抽象出简单友好的接口）

行为模式

涉及对象之间任务的分配以及完成这些任务的算法

• 责任链
  屏幕点击事件从父View传递到子View
• 命令
  EventBus
• 解释器
  解析AndroidManifest.xml
• 中介
  XXManagerService，WindowManagerService，InputManagerService，
  APP之间是跨进程通信，通过Binder实现
• 备忘录
  Activity的onSaveInstanceState和onRestoreInstanceState
• 观察者
  Broadcast Receiver (广播的订阅和发布，发布者和接收者解耦，方便扩展，从权限，时效到优先级，都可高度定制）
• 策略
  Android Animation中使用Interpolator
• 模板
  Activity的生命周期
• 状态
  Wifi状态，数据连接状态，蓝牙耳机状态
• 迭代器
  集合Collection实现了Iterable接口
• 访问者
  APT Dagger

Android中的架构

MVC (Model View Controller)
MVP (Model View Presenter)

• MVC模型

这里写图片描述

• MVP模型

这里写图片描述

• MVC 和 MVP 的区别

这里写图片描述

然而，在实践MVP时，发现Presenter的接口的粒度在组员间很难恰当并且一致的把握。粒度小了臃肿，大了又不够解耦。
之后发现MVVM结合Data Binding库的情况下，粒度的问题就没那么明显，因为自动绑定的机制免去了很多代码，使得代码简介而灵活。

这里写图片描述

MVV图示如上，实线表示必然的联系，虚线表示可能的联系。