Android模块化设计方案之使用代理模式解耦

Posted 2023-05-04

参考技术A

android模块化设计方案系列文章：

1、 Android模块化设计方案模型图

2、 Android模块化设计方案之接口API化

3、 Android模块化设计方案之使用代理模式解耦

本篇是Android模块化设计方案的第三篇，也是对 第一篇 中ThridLibs Proxy模块进行说明。

很多人觉得对那些优秀的第三方依赖库再次封装是一件多余的事情，因为这些库可能出自大神/大厂，或有非常高的star并且使用起来十分稳定，可以在项目中直接拿来使用。当然每个开发者都有自己的态度，我也只是根据以往的经验，表达一下自己的看法。

作为从了解四大组件就不愁找不到工作的互联网大时代中一路走来的Android老鸟，经历了网路请求框架从HttpConnection到Volley再到OkHttp，也经历了图片加载框架从UniversalImageLoader到Picasso再到Gilde，技术的迭代随时都会发生。让项目架构具有良好的扩展性是在设计之初就需要考虑的东西。

那么接下来我用一个简单的demo来演示一下如何使用代理模式对第三方框架进行解耦。

现在我们有一个名为 thirdlib 的模块，为我们提供图片加载功能。

第一步：我们创建了一个新的模块 thridlibproxy ，并且该模块依赖于 thirdlib ，我们在该模块中创建包私有的接口ImageLoaderInterface，这个接口中把thirdlib模块中提供的功能抽象为接口：

第二步：创建包私有的接口的实现类ImageLoaderOneImpl，类中图片加载的业务逻辑是通过调用 thirdlib 中的ImageLoader类实现的：

第三步：我们提供一个供外部调用的ImageLoaderOneImpl接口代理类ImageLoaderProxy：

最后我们就可以通过ImageLoaderProxy中提供的loadImage方法进行图片的加载了。

看到这里有些盆友就会问了，在第二步的时候，我们就完成了 thirdlib 的封装工作，为什么还要有第三步？还有我写一个单例类直接对 thirdlib 进行封装不就行了，为什么还要抽象出接口？

原因很简单，为的就是尽可能的满足软件设计七大原则中的第一个： 开闭原则 。

一个好的软件设计，需要对拓展开放，对修改关闭。我们在设计之初就要想到，在更换图片加载框架之后如何最大程度上满足开闭原则。

如果直接对 thirdlib 进行封装，是面向类的开发而不是面向接口。如果此时更换图片加载类库，那必然会对封装出来的类进行大量的修改，把原来的实现替换为新的实现。

使用代理模式的好处就是，我新创建一个被代理的类ImageLoaderTwoImpl：

然后只需要对第三步中的被代理类进行替换就行了。

在想要达到相同效果的时候，最大程度的满足了开闭原则。

我们业务层模块也和第三方库实现了完全的解耦，我不需要知道 thridlibproxy 是如何帮我完成图片加载工作的，但是只要调用它提供的方法就完事儿的，这也符合软件设计七大原则中的： 最少知道原则 。
关于为何以及怎么通过代理调用第三方依赖库，到这里就介绍完毕了，赶快动手试试吧~

我只想说： 原则是死的，人是活的😹

如果觉得有收获的话，欢迎点赞评论以及关注~

flask基础之LocalProxy代理对象

前言

flask框架自带的代理对象有四个，分别是request,session,g和current_app,各自的含义我们在前面已经详细分析过。使用代理而不是显式的对象的主要目的在于这四个对象使用太过频繁，贯穿整个请求周期，显式传递很容易造成循环导入的问题，需要一个第三方的对象来进行解耦。

代理模式简介

代理模式是程序设计的一种结构模式，其目的是使调用者和执行者之间不发生直接的关系，而是使用一个代理人，这样调用者和执行者就进行了解耦，可以避免许多的问题。

代理模式使用的场景：

• 为真实目标类创建一个对象的代价是昂贵的，而创建代理类很简单；

• 对象必须防止被用户直接使用。

• 当实际请求的时候，为真实目标类创建一个对象会有延迟。

class Boss(object):
    def task1(self):
        print(‘this is task1‘)
    def task2(self):
        print(‘this is task2‘)

class Proxy(object):
    def __init__(self, obj):
        self.proxy = obj
    def task1(self):
        self.proxy.task1()
    def task2(self):
        self.proxy.task2()

proxy_boss = Proxy(Boss())

class Client(object):
    def do_something(self):
        proxy_boss.task1()
if __name__ == ‘__main__‘:
    c = Client()
    c.do_something()

上述的Boss实例不需要显式传递，受到了保护；Proxy对象相当于一个接口的作用。

LocalProxy代理对象

LocalProxy就是flask框架的werkzeug工具实现的一个代理对象，它接收一个可调用的无参数函数作为参数，内部实现了object对象所有的魔法方法的重写，理论上可以代理任何的对象，不管这个对象的结构是怎么样的。

class LocalProxy(object):
    def __init__(self, local, name=None):
        object.__setattr__(self, ‘_LocalProxy__local‘, local)
        object.__setattr__(self, ‘__name__‘, name)

    def _get_current_object(self):
        if not hasattr(self.__local, ‘__release_local__‘):
            return self.__local() # 代理对象local必须是可调用的
        try:
            return getattr(self.__local, self.__name__)
        except AttributeError:
            raise RuntimeError(‘no object bound to %s‘ % self.__name__)

如果我们想在项目中的任何地方使用我们自己的全局代理对象，我们可以这样做：

# myproxy.py
from werkzeug.local import LocalProxy

class Boss(object):
    def pop(self):
        print(‘Ok‘)
        return ‘OK‘
class OtherObj(object):
    def __init__(self,Obj):
        self.real_obj = Obj()
other = OtherObj()
def get_boss(Obj=None):
    return Obj.real_obj
    
proxy_boss = LocalProxy(partial(get_boss, other))

get_boss这种形式是动态代理，也就是说在进程运行中由于OtherObj的real_obj属性可能发生变化，proxy_boss代理的对象可能发生改变。

参考

• https://dormousehole.readthedocs.io/en/latest/