Android 面向接口编程

关键词：Android、POP、面向接口编程 、面向过程、面向协议

一、概述

面向接口编程是面向对象编程的一种实现方式，它的核心思想是将抽象与实现分离，从组件的级别来设计代码，达到高内聚低耦合的目的。最简单的面向接口编程方法是，先定义底层接口模块，再定义高层实现模块。但是这样存在一个问题，就是当修改底层接口的时候，高层实现也需要跟着修改，这也违反了开闭原则。 在面相对象设计基本原则（SOLID）中，依赖倒置原则说得就是这个问题。
同时配合使用依赖注入思想，可以很好地处理这个问题。（PS:注意面向接口编程的接口并不是狭义上指Java中的接口，而是指超类型，可以是接口也可以是抽象类）

二、依赖倒置&依赖注入

依赖倒置原则是高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。这里的抽象就是接口或者抽象类，我们应该依赖接口或者抽象类 ，而不是依赖具体的实现来编程。它应该遵循如下特性：

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

依赖注入是非主动初始化依赖对象，而通过外部来传入依赖的方式，称为依赖注入。它有几个好处：

• 解耦，将依赖之间解耦
• 方便做单元测试，尤其是Mock测试

依赖倒置通常会通过引入中间层来处理模块间交互，这个中间层相当于一个抽象接口层，高层模块和底层模块都依赖于这个中间层来交互，底层模块改变不会影响到高层模块，这就满足了开放关闭原则。而且假如高层模块跟底层模块同时处于开发阶段，这样有了中间抽象层之后，每个模块都可以针对这个抽象层的接口同时开发，高层模块就不需要等到底层模块开发完毕才能继续。举一个例子，

// 抽象：接口
public interface ImageCache {
        ...   
}

// 错误例子：依赖于细节
public class ImageLoader {

        // （直接依赖于细节）
        DoubleCache mCache = new DoubleCache();

        public void displayImage(String url, ImageView imageView) {
                ...
        }

        // (直接依赖于细节）
        public void setImageCache(DoubleCache cache) {
                mCache = cache;
        }

}

// 正确例子：依赖于抽象
public class ImageLoader {

        // 依赖于抽象（接口或者抽象类）
        ImageCache mCache;

        // 设置ImageCache依赖于抽象
        public void setImageCache(ImageCache cache) {
                mCache = cache;
        }

        public void displayImage(String url, ImageView imageView) {
                ...
        }

}

public class Activity{

     ImageLoader mImageLoader;

     mImageLoader.setImageCache(new MemoryCache());// 依赖注入
     mImageLoader.displayImage(...);
}

上面定义的ImageCache就是抽象（接口），它相当于中间层。同时，在传入ImageCache的时候，是通过传入依赖的方式而不是在方法内部生成，这就是依赖注入的思想。

再举一个例子，比如在项目中有涉及IM的功能，现在这个IM模块采用的是XMPP协议来实现，客户端通过这个模块来实现消息的收发，但是假如后面要换成其它协议，比如MQTT等，依赖倒置思想就可以很轻松的实现模块替换：

public interface MessageDelegate{
     void goOnline();
     void sendMessage(String msg);
}

//xmpp实现
public interface XMPPMessageCenter extends MessageDelegate{
     void goOnline();
     void sendMessage(String msg);
}

//MQTT实现
public interface MQTTMessageCenter extends MessageDelegate{
     void goOnline();
     void sendMessage(String msg);
}

//业务层
//使用遵循MessageDelegate协议的对象，针对接口编程，以后替换也很方便
public interface BussinessLayer{
     MessageDelegate messageCenter;
     //业务
     messageCenter.goOnline();
     ...
}

三、策略模式

那么，就很容易联想到面向接口编程的一个典型设计模式，策略模式。 策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。一般的使用场景如下：

• 针对同一类型问题的多种处理方式，仅仅是具体行为有差别时。
• 需要安全的封装多种同一类型的操作时。
• 出现同一抽象多个子类，而又需要使用if-else 或者 switch-case来选择时

Context用来操作策略的上下文环境，Strategy是策略的抽象，ConcreteStrategyA、ConcreteStrategyB等是具体的策略实现。

四、核心要点

1.封装变化

找出程序中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

如何区分变化的和不会变化的就尤为重要，可以简单定义为一切有弹性的无法确定的就作为变化的。举个例子，图像加载的方法就可以作为确定的不会变化的，而图像缓存策略有文件缓存、内存缓存等等，那么就可以作为变化的。所以，缓存相关部分的代码就需要独立出来，不跟其他代码混在一起。

2.将行为转为属性

区分好变化与不变化部分之后，将变化的部分抽象为接口或者抽象类 ，然后在调用处转为属性。

在调用处，将接口或者抽象类转为属性，也就是声明为成员变量，这样在方法中具体调用的时候，就会根据行为实现的不同而产生不同的结果。

五、实际应用

在安卓开发中，有各种基础功能的类库，比如网络请求、图像加载、日志输出、数据存储等等。一般情况下，开源社区也有比较成熟的实现方案，项目有时候也会使用不同的方案。那么，如何定义一个架构，既可以自己去实现开发方案，同时也可以使用其他方案呢？答案就是利用策略模式，同时配合使用建造者模式、单例模式等，根据面向接口编程的思想去完成。下面以图像加载功能为例，去实现一个图像加载类库。

目前比较流行的图像加载类库有Glide、Fresco、Picasso、UML等，从对这些类库的使用来看，对外提供的功能接口很多都比较类似，例如图像加载、缓存清理、额外配置等等。因此就可以从这些类库中提出公关接口部分出来，形成一个基础图像加载架构，然后再继续进行适配。先各自看一下加载图像的API方法：

1、Glide

Glide.with(getContext()).load(url).skipMemoryCache(true).placeholder(drawable).centerCrop().animate(animator).into(img);

2、Fresco

Uri uri = "file:///mnt/sdcard/MyApp/myfile.jpg";
int width = 50, height = 50;
ImageRequest request = ImageRequestBuilder.newBuilderWithSource(uri)
    .setResizeOptions(new ResizeOptions(width, height))
    .build();
PipelineDraweeController controller = Fresco.newDraweeControllerBuilder()
    .setOldController(mDraweeView.getController())
    .setImageRequest(request)
    .build();
mSimpleDraweeView.setController(controller);

3、Picasso

 Picasso.with(context).load(url).resize(50, 50).centerCrop().into(imageView);

4、Universal Image Loader

ImageLoader.getInstance().displayImage(imageUri, imageView, options, new ImageLoadingListener() {
    @Override
    public void onLoadingStarted(String imageUri, View view) {
        ...
    }
    @Override
    public void onLoadingFailed(String imageUri, View view, FailReason failReason) {
        ...
    }
    @Override
    public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {
        ...
    }
    @Override
    public void onLoadingCancelled(String imageUri, View view) {
        ...
    }
}, new ImageLoadingProgressListener() {
    @Override
    public void onProgressUpdate(String imageUri, View view, int current, int total) {
        ...
    }
});

从上面可以发现，Glide和Picasso的使用方式几乎是一致的，通过链式调用，进行各自图像加载的配置，如缓存策略，动画，占位符等等。Universal Image Loader方法比较常规，通过单例模式进行图像加载方法的调用，方法参数包含有加载配置、回调接口等。而Fresco有一套自己的逻辑，把图像加载的逻辑封装到了UI中。对于图片加载而言，有最基本最重要的必选项，以及可有可无的可选项，从上面方法中提取必选项以及可选项：

• 必选项：上下文环境（Context），URI（图片来源），ImageView(图片容器)
• 可选项：Options （是否缓存、图像大小、圆角、动画、回调、缺省图等等）

那么可以这样设计接口，

public interface ImageLoaderStrategy{

     void showImage(ImageView imageview, String url, ImageLoaderOptions options);
     void showImage(ImageView imageview, int drawable, ImageLoaderOptions options);

}

当然对于必选项与可选项其实并没有严格的规范，例如Fresco的特殊设计，自己实现了图片容器而不是ImageView，这时候要么再添加一个方法：

void showImage(View view, int drawable, ImageLoaderOptions options);

要么就可以进一步拆分，把View和URI也加入到可选项中，然后使用泛型来动态设置可选项，如下：

public interface ImageLoaderStrategy<T extends ImageLoaderOptions> {
    void loadImage(Context ctx, T options);
}

ImageLoaderOptions就是可选项，这些可选项可以从开源类库中提出公共的部分，由于这些属性都是可选择的，因此最好使用Builder模式来构建。

public class ImageLoaderOptions{

    protected String url;
    protected ImageView imageView;
    protected int placeholder;
    protected int errorPic;

    public String getUrl() {
        return url;
    }

    public ImageView getImageView() {
        return imageView;
    }

    public int getPlaceholder() {
        return placeholder;
    }

    public int getErrorPic() {
        return errorPic;
    }

}

然后根据策略模式，设计出图像加载的基本框架：

最后再去实现其他部分，整体方案的设计并不难，涉及到具体实现就需要细心去写代码了。所以在进行面向接口编程时候，前期最关键的还是架构的设计，如何能够保证易拓展、易维护、易、易兼容等。架构设计好之后就是细节的实现，可以直接使用开源方案来组装，或者创造轮子再去实现一套新的方案。