Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1104319
  • 博文数量: 695
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 4027
  • 用 户 组: 普通用户
  • 注册时间: 2013-11-20 21:22
文章分类

全部博文(695)

文章存档

2018年(18)

2017年(74)

2016年(170)

2015年(102)

2014年(276)

2013年(55)

分类: Java

2016-07-14 12:28:35

依赖倒置:抽象不依赖具体类,类依赖抽象

控制反转:对于软件来说,即是某一接口具体实现类的选择控制权从调用类中移除,转交给第三方决定。  

因为IoC确实不够开门见山,因此业界曾进行了广泛的讨论,最终软件界的泰斗级人物Martin Fowler提出了DI(依赖注入:Dependency Injection)的概念用以代替IoC,即让调用类对某一接口实现类的依赖关系由第三方(容器或协作类)注入,以移除调用类对某一接口实现类的依赖。 “依赖注入”这个名词显然比“控制反转”直接明了、易于理解。

依赖注入:控制反转的一种实现思想

http://www.cnblogs.com/fuchongjundream/p/3873073.html

1.依赖

依赖就是有联系,有地方使用到它就是有依赖它,一个系统不可能完全避免依赖。如果你的一个类或者模块在项目中没有用到它,恭喜你,可以从项目中剔除它或者排除它了,因为没有一个地方会依赖它。下面看一个简单的示例:

点击(此处)折叠或打开

  1. ///
  2.     /// 用户播放媒体文件
  3.     ///
  4.     public class OperationMain
  5.     {
  6.         public void PlayMedia()
  7.         {
  8.             MediaFile _mtype = new MediaFile();
  9.             Player _player = new Player();

  10.             _player.Play(_mtype);
  11.         }
  12.     }
  13.     ///
  14.     /// 播放器
  15.     ///
  16.     public class Player
  17.     {
  18.         public void Play(MediaFile file)
  19.         {
  20.             Console.WriteLine(file.FilePath);
  21.         }
  22.     }
  23.     ///
  24.     /// 媒体文件
  25.     ///
  26.     public class MediaFile
  27.     {
  28.         public string FilePath { get; set; }
  29.     }
上面是一个用户用播放器播放文件简单示例,用户操作是OperationMain类中的PlayMedia方法,打开一个播放器,选择一个文件来播放。先看看他们之间的依赖关系,可以简单找到有3个依赖
  1. Player依赖MediaFile
  2. OperationMain依赖Player
  3. OperationMain依赖MediaFile

2.依赖倒置

需求增加了,要用不同的播放器,播放不同的文件,我们要抽象出来,减少耦合。

耦合关系就是依赖关系,如果依赖关系相当繁杂,牵一发而动全身,很难维护;依赖关系越少,耦合关系就越低,系统就越稳定,所以我们要减少依赖。

幸亏Robert Martin大师提出了面向对象设计原则----依赖倒置原则:   

  • A. 上层模块不应该依赖于下层模块,它们共同依赖于一个抽象。  
  • B. 抽象不能依赖于具象,具象依赖于抽象。

理解:A.上层是使用者,下层是被使用者,这就导致的结果是上层依赖下层了,下层变动了,自然就会影响到上层了,导致系统不稳定,甚至是牵一发而动全身。那怎么减少依赖呢?就是上层和下层都去依赖另一个抽象,这个抽象比较稳定,整个就来说就比较稳定了。

B.面向对象编程时面向抽象或者面向借口编程,抽象一般比较稳定,实现抽象的具体肯定是要依赖抽象的,抽象不应该去依赖别的具体,应该依赖抽象。


上面播放器的示例中,我们已经找到依赖关系了,现在我们要按照依赖倒置原则,来进行优化。

根据原则如下改动:

  • Player依赖MediaFile,好办,让Player和MediaFile都去依赖一个抽象IMediaFile
  • OperationMain依赖Player,好办,让OperationMain和Player都依赖一个抽象IPlayer
  • OperationMain依赖MediaFile,好办,让OperationMain和MediaFile都依赖一个抽象IMediaFile
  • IPlayer不能依赖具体MediaFile,应该依赖于具体MediaFile的抽象IMediaFile

结构很简单,于是代码大致如下:

点击(此处)折叠或打开

  1. ///
  2.     /// 用户播放媒体文件
  3.     ///
  4.     public class OperationMain
  5.     {
  6.         public void PlayMedia()
  7.         {
  8.             IMediaFile _mtype = new MediaFile();
  9.             IPlayer _player = new Player();

  10.             _player.Play(_mtype);
  11.         }
  12.     }
  13.     ///
  14.     /// 播放器
  15.     ///
  16.     public interface IPlayer
  17.     {
  18.         void Play(IMediaFile file);
  19.     }
  20.     ///
  21.     /// 默认播放器
  22.     ///
  23.     public class Player : IPlayer
  24.     {
  25.         public void Play(IMediaFile file)
  26.         {
  27.             Console.WriteLine(file.FilePath);
  28.         }
  29.     }
  30.     ///
  31.     /// 媒体文件
  32.     ///
  33.     public interface IMediaFile
  34.     {
  35.         string FilePath { get; set; }
  36.     }
  37.     ///
  38.     /// 默认媒体文件
  39.     ///
  40.     public class MediaFile : IMediaFile
  41.     {
  42.         public string FilePath { get; set; }
  43.     }

上面代码进行了抽象,可以看到,目的是减少了依赖,但是看上去依赖关系增加了,如用户PlayMedia方法,依赖还增加了依赖接口和具体的实现,但是接口是稳定的,可以不考虑,具体的实现才是变动的,这个依赖还是要的,要播放文件,必定要用到具体的播放器和具体文件。

3.控制反转(IoC)

现实生活中,是具体的播放器和具体的媒体文件没有关系,你给它一个Mp3文件他可以播放,给它一个Mp4文件它也可以播放,你删掉你的媒体文件,播放器照样在,具体什么播放器,播放什么文件,控制权全部是我们用户自己。

上面的示例中基本实现了隔离,具体的播放器跟具体的媒体隔离了,具体的播放器只跟媒体接口和播放器接口有关。但是PlayMedia的方法里面的具体对象,写死了,控制权非常小,如果我想用百度影音播放呢,我想换一首音乐呢,只能重新改代码,那控制怎么进行转移呢?

我们可以通过反射来创建,把具体的文件名写在配置文件里,这时候客户端代码也不用变了,只需要改配置文件就好了,稳定性又有了提高,如下:

点击(此处)折叠或打开

  1. public void PlayMedia()
  2.         {
  3.             IMediaFile _mtype = Assembly.Load(ConfigurationManager.AppSettings["AssemName"]).CreateInstance(ConfigurationManager.AppSettings["MediaName"]);
  4.             IPlayer _player = Assembly.Load(ConfigurationManager.AppSettings["AssemName"]).CreateInstance(ConfigurationManager.AppSettings["PlayerName"]);

  5.             _player.Play(_mtype);
  6.         }
这个具对象是哪一个,全由配置文件来控制了,这个具体对象的控制权交给了配置文件了,这也是人们常说的控制反转。

控制反转IoC是Inversion of Control的缩写,是说对象的控制权进行转移,转移到第三方,比如转移交给了IoC容器,它就是一个创建工厂,你要什么对象,它就给你什么对象,有了IoC容器,依赖关系就变了,原先的依赖关系就没了,它们都依赖IoC容器了,通过IoC容器来建立它们之间的关系。

4.依赖注入(DI)

上面说到控制反转,是一个思想概念,但是也要具体实现的,上面的配置文件也是一种实现方式。依赖注入提出了具体的思想。

依赖注入DI是Dependency Injection缩写,它提出了“哪些东东的控制权被反转了,被转移了?”,它也给出了答案:“依赖对象的创建获得被反转”。

所谓依赖注入,就是由IoC容器在运行期间,动态地将某种依赖关系注入到对象之中。

上面的示例中,哪些要依赖注入,依赖对象需要获得实例的地方,即 PlayMedia方法,需要IPlayer具体对象和IMediaFile的具体对象,找到了地方就从这里下手,为了灵活的控制这两个对象,必须是外面能够控制着两个对象的实例化,提供对外的操作是必要的,可以是属性,可以是方法,可以是构造函数,总之别的地方可以控制它,下面将会使用Unity来注入,使用的是构造函数注入,代码如下:

点击(此处)折叠或打开

  1. ///
  2.     /// 用户播放媒体文件
  3.     ///
  4.     public class OperationMain
  5.     {
  6.         IMediaFile _mtype;
  7.         IPlayer _player;

  8.         public OperationMain(IPlayer player, IMediaFile mtype)
  9.         {
  10.             _player = player;
  11.             _mtype = mtype;
  12.         }

  13.         public void PlayMedia()
  14.         {
  15.             _player.Play(_mtype);
  16.         }
  17.     }
  18.     ///
  19.     /// 播放器
  20.     ///
  21.     public interface IPlayer
  22.     {
  23.         void Play(IMediaFile file);
  24.     }
  25.     ///
  26.     /// 默认播放器
  27.     ///
  28.     public class Player : IPlayer
  29.     {
  30.         public void Play(IMediaFile file)
  31.         {
  32.             Console.WriteLine(file.FilePath);
  33.         }
  34.     }
  35.     ///
  36.     /// 媒体文件
  37.     ///
  38.     public interface IMediaFile
  39.     {
  40.         string FilePath { get; set; }
  41.     }
  42.     ///
  43.     /// 默认媒体文件
  44.     ///
  45.     public class MediaFile : IMediaFile
  46.     {
  47.         public string FilePath { get; set; }
  48.     }
给 OperationMain类一个构造函数,因为Unity有一个构造函数注入,调用代码如下:

点击(此处)折叠或打开

  1. static UnityContainer container = new UnityContainer();
  2.         static void init()
  3.         {
  4.             container.RegisterType<IPlayer, Player>();
  5.             container.RegisterType<IMediaFile, MediaFile>();
  6.         }
  7.         static void Main(string[] args)
  8.         {

  9.             init();

  10.             OperationMain op1 = container.Resolve<OperationMain>();
  11.             op1.PlayMedia();
  12.             OperationMain op3 = container.Resolve<OperationMain>();
  13.             op3.PlayMedia();

  14.             //普通方式
  15.             OperationMain op2 = new OperationMain(new Player(), new MediaFile());
  16.             op2.PlayMedia();

  17.             Console.Read();
  18.         }

 

看出来吧,Unity的功能远不止这些,你可以初始化时注册N多,以后直接使用,而不用使用new,还有实例周期的控制、配置文件等灵活控制,具体可以看看Unity(具体不是本节的范畴)的说明。

5.小结

通过一个小例子由浅入深地进行优化,已加深对IoC模式的理解,我想复杂的结构也是从这种简单的架构累加起来的。

最近在看相关文章,很多都太专业化了没怎么看懂,这是自己现在对IoC的一些理解,记录下来,要不然时间一久,也就忘了。

自己对IoC模式理解还很浅,希望得到各位的指点。

阅读(332) | 评论(0) | 转发(0) |
0

上一篇:java三大框架

下一篇:透透彻彻IoC

给主人留下些什么吧!~~