移动开发中的IoC思想

@chengyong  June 21, 2019

在平时的面试或者开发过程中,经常遇到一个词汇:“依赖注入”,这个其实是一个编程的高级用法,跟这个词关联的设计思想就是IoC(Inversion of Control)设计原则。

IoC中文名为控制反转,在Java开发中,IoC意味着将你设计好的类交给系统去控制,而不是在你的类内部控制,这就存在控制权的对调,所以称为控制反转。

举个形象的栗子:

假设我们设计一辆汽车:先设计轮子,然后根据轮子大小设计底盘,接着根据底盘设计车身,最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系:汽车依赖车身,车身依赖底盘,底盘依赖轮子。

这样的设计看起来没问题,但是可维护性却很低。假设设计完工之后,上司却突然说根据市场需求的变动,要我们把车子的轮子设计都改大一码。这下我们就蛋疼了:因为我们是根据轮子的尺寸设计的底盘,轮子的尺寸一改,底盘的设计就得修改;同样因为我们是根据底盘设计的车身,那么车身也得改,同理汽车设计也得改——整个设计几乎都得改!

我们现在换一种思路。我们先设计汽车的大概样子,然后根据汽车的样子来设计车身,根据车身来设计底盘,最后根据底盘来设计轮子。这时候,依赖关系就倒置过来了:轮子依赖底盘, 底盘依赖车身, 车身依赖汽车。

这时候,上司再说要改动轮子的设计,我们就只需要改动轮子的设计,而不需要动底盘,车身,汽车的设计了。这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来,变成底层建筑依赖高层建筑。高层建筑决定需要什么,底层去实现这样的需求,但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。

再来个栗子:

假设我们要设计一个Girl和一个Boy类,其中Girl有kiss方法,即Girl想要Kiss一个Boy。那么,我们的问题是,Girl如何能够认识这个Boy?

在我们中国,常见的MM与GG的认识方式有以下几种:

1、青梅竹马:
Girl从小就知道自己的Boy。

public class Girl {  
    void kiss(){
       Boy boy = new Boy();
    }
}

然而从开始就创建的Boy缺点就是无法在更换。并且要负责Boy的整个生命周期。如果我们的Girl想要换一个怎么办?(笔者严重不支持Girl经常更换Boy)

2、亲友介绍:
由中间人负责提供Boy来见面。

public class Girl {
    void kiss(){
       Boy boy = BoyFactory.createBoy();      
    }
}

亲友介绍,固然是好。如果不满意,尽管另外换一个好了。但是,亲友BoyFactory经常是以Singleton的形式出现,不然就是,存在于Globals,无处不在,无处不能。实在是太繁琐了一点,不够灵活。我为什么一定要这个亲友掺和进来呢?为什么一定要付给她介绍费呢?万一最好的朋友爱上了我的男朋友呢?

3、父母包办:
一切交给父母,自己不用费吹灰之力,只需要等着Kiss就好了。

public class Girl {
    void kiss(Boy boy){
       // kiss boy  
      boy.kiss();
    }
}

Well,这是对Girl最好的方法,只要想办法贿赂了Girl的父母,并把Boy交给他。那么我们就可以轻松的和Girl来Kiss了。看来几千年传统的父母之命还真是有用哦。至少Boy和Girl不用自己瞎忙乎了。

这就是IoC,将对象的创建和获取提取到外部,将自己的需求表达出去,将控制权反转,实现上层对下层的“控制”。

在实际开发过程中,肯定会涉及到类与类之间的依赖,如果直接new Object出来就会出现耦合的问题,特别是涉及到跨组件的开发,有时候一个组件的功能依赖另一个组件,但我们实际上并不太想让组件之间有过多的耦合,那么这时候IoC的思想就有很大的用处了。

参考链接:https://www.zhihu.com/question/23277575/answer/169698662
参考链接:http://www.nowamagic.net/librarys/veda/detail/393



添加新评论