依赖倒置(DIP)与依赖注入(DI)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

  依赖倒置原则(Dependency Inversion Principle)为我们提供了降低模块间耦合度的一种思路,依赖注入(Dependency Injection)是一种具体的实施方法。

依赖倒置原则:

  前面一篇讲软件设计原则的文章中已经提到了“依赖倒置原则”(Dependency Inversion Principle),该原则主要是为了降低模块与模块之间的“耦合度”,提倡模块与模块之间不要发生直接的依赖关系,即:高层模块不应该直接依赖于低层模块,高层模块和低层模块应该同时依赖一个抽象层。如果现在有一个类Manager在处理某一任务时,需要记录错误日志,那么我们可以这样编写代码:

  View Code

如上代码所示,FileLogger类负责将错误日志保存到文件,Manager类中定义了一个Logger类对象,专门负责记录错误日志,这段代码中的“高层模块”Manager类就直接依赖与“低层模块”FileLogger,如果我们现在需要将错误日志记录通过Email发送给别人,或者发送给别的模块,我们不得不去修改Manager类的代码。

  “依赖倒置原则”建议我们,Manager类不应该直接依赖于FIleLogger类,而应该依赖一个抽象层(接口层),所以原来代码应该这样写:

  View Code

如上代码所示,我们把记录错误日志的逻辑抽象出来一个ILog接口,Manager类不再依赖于任何一个具体的类,而是依赖于ILog接口,同时我们可以根据ILog接口实现各种各样的日志记录类,如FileLogger将日志保存到文件、EmailLogger将日志以邮件形式发送给别人、NotifyLogger将错误信息通知程序中其他模块。这样以来,整个代码的灵活度明显增加了,如果我们需要将日志保存到文件,直接使用FileLogger,如果我们想将日志以邮件形式发送别人,直接使用EmailLogger等等。下图显示依赖倒置发生前后:

 

依赖注入:

  上面的Manager类虽然不再直接依赖任何具体的日志记录类型,但是实质上,我们创建记录日志类对象还是在Manager内部(catch中),如果我们想换种方式记录日志,还是得动Manager类的代码,有没有一种方式,能够让我们不需要修改Manager代码就能切换日志的记录方式呢?当然是有的,“依赖注入”就是这一问题的具体解决方法,我们有三种方式去让两个类型发生依赖关系:

(1)构造注入(Constructor Injection)

  在我们创建Manager对象的时候,将记录日志的对象作为构造参数传递给新创建的Manager对象,假设Manager有一个带ILog类型参数的构造方法,如:

  View Code

那么,我们在创建Manager对象的时候,这样编写代码:

  Manager m = new Manager(new FileLogger());

  //Manager m = new Manager(new EmailLogger());

  //Manager m = new Manager(new NotifyLogger());

很明显,这种日志记录方式一直不变,对Manager终生有效。

(2)方法注入(Method Injection)

  为Manager类中每个需要记录日志的方法增加一个ILog的参数,比如Manager.DoSomething方法重新定义为:

  View Code

那么我们之后在使用Manager的时候,每次调用方法都应该为它提供一个记录日志的对象,如:

  Manager m = new Manager();

  m.DoSomething(new FileLogger());

  m.DoSomething(new EmailLogger());

  m.DoSomething(new NotifyLogger());

这种记录日志的方式,只对当前方法有效,每次调用方法都可以不同。

(3)属性注入(Property Injection)

  在Manager类中公开一个属性,用来设置日志记录对象,Mananger这样定义:

  View Code

之后我们使用Mananger时,可以随时更换它的日志记录方式:

  Mananger m = new Manager();

  m.Logger = new FileLogger();

  m.Logger = new EmailLogger();

  m.Logger = new NotifyLogger();

使用这种方式,我们可以随时切换记录日志的方式,它的灵活度介于“构造注入”和“方法注入”之间。

  以上三种依赖注入方法可以混合使用,也就是说,你可以为Manager类定义一个带ILog类型的参数,同时也可以定义一个ILog类型的属性,或者为每个方法增加一个ILog类型的参数。

  注:

    1】在.NET中,“抽象层”可以不使用接口interface去实现,而是直接使用委托,举一个例子,我们使用FileStream.BeginRead方法时,给它提供的一个AsyncCallback回调参数,其实就是属于“方法注入”的一种。

   2】类型与类型之间不可能完全失去依赖关系,怎样让这种非有不可的依赖关系更微弱,是软件设计的一门高深学问。

 

上一篇设计原则(倒数第二小节)  http://www.cnblogs.com/xiaozhi_5638/p/3610706.html

作者:周见智 
出处:http://www.cnblogs.com/xiaozhi_5638/ 
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

分类:  架构设计
标签:  c#架构设计

本文转自周见智博客博客园博客,原文链接:http://www.cnblogs.com/xiaozhi_5638/p/3613176.html,如需转载请自行联系原作者
相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
目录
相关文章
|
11月前
|
Cloud Native Devops 虚拟化
Docker和VMWare有什么不同
【10月更文挑战第18天】Docker和VMWare有什么不同
|
7月前
|
人工智能 测试技术
QVQ-72B-Preview:阿里通义千问最新多模态推理模型,视觉推理助力复杂图像理解
阿里云通义千问团队开源的多模态推理模型 QVQ-72B-Preview,专注于提升视觉推理能力,支持复杂图像理解和逐步推理。
475 6
QVQ-72B-Preview:阿里通义千问最新多模态推理模型,视觉推理助力复杂图像理解
|
6月前
|
人工智能 自然语言处理 安全
Axcxept携手阿里云,打造日语“首选”LLM——EZO×Qwen2.5
Axcxept携手阿里云,打造日语“首选”LLM——EZO×Qwen2.5
|
存储 JavaScript 索引
TypeScript 中的元组类型:元组的特性、常见操作和注意事项
TypeScript 中的元组类型:元组的特性、常见操作和注意事项
381 1
|
负载均衡 监控 NoSQL
Redis的几种主要集群方案
【5月更文挑战第15天】Redis集群方案包括主从复制(基础,读写分离,手动故障恢复)、哨兵模式(自动高可用,自动故障转移)和Redis Cluster(官方分布式解决方案,自动分片、容错和扩展)。此外,还有Codis、Redisson和Twemproxy等工具用于代理分片和负载均衡。选择方案需考虑应用场景、数据量和并发需求,权衡可用性、性能和扩展性。
439 2
|
运维 Cloud Native 持续交付
运维之道:从传统到云原生的演变
本文通过探索运维(Operations)的历史脉络,从早期的手工操作到自动化脚本,再到现代的云原生技术,揭示运维工作的演进如何与技术创新相互促进。文章将重点讨论云原生环境下的运维实践,包括容器化、持续集成/持续部署(CI/CD)、微服务架构以及自动化测试等概念,并探讨这些变革如何影响运维团队的日常工作。
|
Ubuntu Linux 数据安全/隐私保护
Linux yum 使用时提示 获取 GPG 密钥失败Couldn‘t open file RPM-GPG-KEY-EPEL-7
Linux yum 使用时提示 获取 GPG 密钥失败Couldn‘t open file RPM-GPG-KEY-EPEL-7
317 3
Netty ChannelFuture 监听三种方法
Netty ChannelFuture 监听三种方法
158 0
|
消息中间件 负载均衡 Kafka
一文读懂Kafka API:Producer、Consumer和Streams全解析
大家好,今天我们将深入探讨Kafka的三大核心API。通过这篇文章,你将了解如何使用Producer API发布记录流,利用Consumer API订阅和处理数据,以及通过Streams API实现复杂的流处理。一起开启Kafka的探索之旅吧!
417 2