阅读 248

利用设计模式封装网络请求框架

在项目中有这样一种场景,我们的APP分为内网外网两个版本,内外网项目有一些公共功能,这些公共功能的代码可以复用。

其中有一些网络请求。

但是内外网代码所用的网络请求框架并不一致,外网APP用的是OkHttp加Retrofit,内网APP用的是公司内部的一个网络框架

那应该如何封装这些网络请求呢?如何做到复用公共代码?

如何做到内外网项目代码的复用与网络功能的隔离?

原始版本

内外网使用不同网络请求库,导致每个网络请求都要写两遍,不利于代码维护与扩展

项目结构大致如下:

使用外观模式优化

定义

要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行,门面模式提供了一个高层次的接口,使得子系统更易于使用;

目的

(1)门面对象是通往外界子系统内部的唯一通道;

(2)通过门面对象降低程序耦合;

外观模式可以使客户端与第三方库(子系统)解耦,让子系统内部模块功能更容易拓展和维护。 同时满足单一职责原则:客户端根本不需要知道第三方系统提供什么功能甚至不需要知道第三方系统如何使用,只需要和中间门面类交互即可。 因为网络请求都可以大致分为get,post,patch,delete等几种类型,定义一个外观类实现这几个接口即可实现封装

项目结构大致如下:

优点

1.降低耦合,减少了系统依赖

2.职责分明,不管第三方库如何修改,只要不影响门面,客户都可以自由行动

缺点

1.当第三方库修改的时候,要需要对外观类进行修改,违反了对扩展开放,对修改关闭的开闭原则

2.公共库同时依赖两个网络请求库,有重复依赖,导致APK体积变大,这个问题更大.

使用代理模式优化

定义

给目标对象提供一个代理对象,并由代理对象控制对目标对象的引用;

目的

(1)通过引入代理对象的方式来间接访问目标对象,防止直接访问目标对象给系统带来的不必要复杂性;

(2)通过代理对象对原有的业务增强;

项目结构大致如下:

在Application中初始化的时候,不同的项目初始化不同的代理对象,这样就实现了对不同网络框架的兼容,增强了系统了扩展性。

同时不同的项目只需要依赖自已的网络框架,减小了包的体积.

总结

最终通过代理模式,实现了网络请示模块的封装与隔离,实现了复用公共代码的效果,减少了对网络请示框架的依赖,增强了系统的扩展性与可维护性,同时也减小了包的体积。