设计模式——控制反转&依赖注入

简介:

一、控制反转:

从简单的代码示例入手:

    /// <summary>
    /// 邮件服务类
    /// </summary>
    public class EmailService
    {
        public string SendMessage()
        {
            return "发送通知邮件";
        }
    }

    /// <summary>
    /// 邮件通知类
    /// </summary>
    public class NotifycationSystem
    {
        private EmailService service;
        public NotifycationSystem()
        {
            service = new EmailService(); //邮件通知类必须精确的知道创建和使用了哪种类型的服务,此处高耦合了。
        }
        public string InterestingEventHappened()
        {
            return service.SendMessage();
        }
    }
共两个类,一个邮件服务类,一个邮件通知类,邮件通知类依赖于邮件服务类。邮件通知类必须精确的知道创建和使用了哪种类型的服务,此处高耦合了。

改进一:在两代码块中引入抽象层,提取接口。

    /// <summary>
    /// 邮件服务接口
    /// </summary>
    public interface IMessageService
    {
        string SendMessage();
    }

    /// <summary>
    /// 邮件服务类
    /// </summary>
    public class EmailService : IMessageService
    {
        public string SendMessage()
        {
            return "发送通知邮件";
        }
    }

    /// <summary>
    /// 邮件通知类
    /// </summary>
    public class NotifycationSystem
    {
        private IMessageService service;//邮件通知类保存服务实现的接口
        public NotifycationSystem()
        {
            service = new EmailService(); 
        }
        public string InterestingEventHappened()
        {
            return service.SendMessage();
        }
    }
上面将依赖具体实现改为了依赖接口,减少了部分耦合。但是邮件服务类还是在邮件通知类内实例化的,也就是说邮件通知类还是要完全知道邮件服务类的具体细节。

改进二:将选择抽象实现的责任移到服务消费者类的外部。

    /// <summary>
    /// 第二层抽象: 服务定位器
    /// </summary>
    public interface IServiceLocator
    {
        IMessageService GetMessageService();
    }

    /// <summary>
    /// 第一层抽象:邮件服务接口
    /// </summary>
    public interface IMessageService
    {
        string SendMessage();
    }

    /// <summary>
    /// 邮件服务类
    /// </summary>
    public class EmailService : IMessageService
    {
        public string SendMessage()
        {
            return "发送通知邮件";
        }
    }

    /// <summary>
    /// 邮件通知类
    /// </summary>
    public class NotifycationSystem
    {
        private IMessageService service;//邮件通知类保存服务实现的接口。
        public NotifycationSystem(IServiceLocator locator)
        {
            service = locator.GetMessageService();//实现依赖关系被转移到类外。
        }
        public string InterestingEventHappened()
        {
            return service.SendMessage();
        }
    }
扩展一:弱类型服务定位器。

/// <summary>
    /// 第二层抽象: 服务定位器
    /// </summary>
    public interface IServiceLocator
    {
        object GetService(Type serviceType);
    }

    /// <summary>
    /// 第一层抽象:邮件服务接口
    /// </summary>
    public interface IMessageService
    {
        string SendMessage();
    }

    /// <summary>
    /// 邮件服务类
    /// </summary>
    public class EmailService : IMessageService
    {
        public string SendMessage()
        {
            return "发送通知邮件";
        }
    }

    /// <summary>
    /// 邮件通知类
    /// </summary>
    public class NotifycationSystem
    {
        private IMessageService service;//邮件通知类保存服务实现的接口。
        public NotifycationSystem(IServiceLocator locator)
        {
            service = (IMessageService)locator.GetService(typeof(IMessageService));//实现依赖关系被转移到类外。
        }
        public string InterestingEventHappened()
        {
            return service.SendMessage();
        }
    }

弱类型服务定位器使得这种模式更加灵活,因为他允许请求任意类型的服务类型。采用Type类型的参数,并返回一个非类型化的示例,也就是一个object类型对象。

扩展二:泛型方法。

    /// <summary>
    /// 第二层抽象: 服务定位器
    /// </summary>
    public interface IServiceLocator
    {
        T GetService<T>();//泛型接口
        object GetService(Type serviceType);
    }

    /// <summary>
    /// 第一层抽象:邮件服务接口
    /// </summary>
    public interface IMessageService
    {
        string SendMessage();
    }

    /// <summary>
    /// 邮件服务类
    /// </summary>
    public class EmailService : IMessageService
    {
        public string SendMessage()
        {
            return "发送通知邮件";
        }
    }

    /// <summary>
    /// 邮件通知类
    /// </summary>
    public class NotifycationSystem
    {
        private IMessageService service;//邮件通知类保存服务实现的接口。
        public NotifycationSystem(IServiceLocator locator)
        {
            service = locator.GetService<IMessageService>();//实现依赖关系被转移到类外。
        }
        public string InterestingEventHappened()
        {
            return service.SendMessage();
        }
    }
泛型方法,让依赖反转代码看上去更加高效优雅。

二、依赖注入:

1.构造函数注入:

    /// <summary>
    /// 邮件通知类
    /// </summary>
    public class NotifycationSystem
    {
        private IMessageService _service;
        public NotifycationSystem(IMessageService service)//构造函数注入
        {
            _service = service;
        }
        public string InterestingEventHappened()
        {
            return _service.SendMessage();
        }
    }
2.属性注入:

    /// <summary>
    /// 邮件通知类
    /// </summary>
    public class NotifycationSystem
    {
        private IMessageService MessageService { get; set; }
        public string InterestingEventHappened()
        {
            if (MessageService == null)
            {
                throw new InvalidOperationException("服务类型为赋值!");
            }
            return MessageService.SendMessage();
        }
    }




目录
相关文章
|
9月前
|
设计模式 Java uml
C++设计模式之 依赖注入模式探索
C++设计模式之 依赖注入模式探索
339 0
|
2月前
|
设计模式 XML Java
【23种设计模式·全精解析 | 自定义Spring框架篇】Spring核心源码分析+自定义Spring的IOC功能,依赖注入功能
本文详细介绍了Spring框架的核心功能,并通过手写自定义Spring框架的方式,深入理解了Spring的IOC(控制反转)和DI(依赖注入)功能,并且学会实际运用设计模式到真实开发中。
【23种设计模式·全精解析 | 自定义Spring框架篇】Spring核心源码分析+自定义Spring的IOC功能,依赖注入功能
|
设计模式 消息中间件 XML
一起来学设计模式之依赖注入模式
前言 目前正在出一个设计模式专题系列教程, 篇幅会较多, 喜欢的话,给个关注❤️ ~ 本节给大家讲一下设计模式中的依赖注入模式,并结合实际业务场景给大家讲解如何使用~ 本专题的所有案例代码主要以Java语言为主, 好了, 废话不多说直接开整吧~ 依赖注入模式 Dependency Injection(依赖注入)是一种设计模式,用于解决对象之间的耦合关系问题,一个对象通常会通过New操作符显式创建出它所需要的相关对象,这样会导致对象之间高度耦合、难以重用、难以测试等问题。而Dependency Injection则是一种反向控制的思想,即对象不再直接操作其他对象,而是通过容器(例如Spring)
|
存储 PHP 容器
设计模式之————依赖注入(Dependency Injection)与控制反转(Inversion of Controller)
参考链接: 依赖注入(DI) or 控制反转(IoC) laravel 学习笔记 —— 神奇的服务容器 PHP 依赖注入,从此不再考虑加载顺序 名词解释 IoC(Inversion of Controller) 控制反转(概念) DI(Dependency Inject) 依赖注入(IoC...
1944 0
|
2月前
|
设计模式 前端开发 搜索推荐
前端必须掌握的设计模式——模板模式
模板模式(Template Pattern)是一种行为型设计模式,父类定义固定流程和步骤顺序,子类通过继承并重写特定方法实现具体步骤。适用于具有固定结构或流程的场景,如组装汽车、包装礼物等。举例来说,公司年会节目征集时,蜘蛛侠定义了歌曲的四个步骤:前奏、主歌、副歌、结尾。金刚狼和绿巨人根据此模板设计各自的表演内容。通过抽象类定义通用逻辑,子类实现个性化行为,从而减少重复代码。模板模式还支持钩子方法,允许跳过某些步骤,增加灵活性。
137 11
|
3月前
|
设计模式 安全 Java
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
|
24天前
|
设计模式
「全网最细 + 实战源码案例」设计模式——模式扩展(配置工厂)
该设计通过配置文件和反射机制动态选择具体工厂,减少硬编码依赖,提升系统灵活性和扩展性。配置文件解耦、反射创建对象,新增产品族无需修改客户端代码。示例中,`CoffeeFactory`类加载配置文件并使用反射生成咖啡对象,客户端调用时只需指定名称即可获取对应产品实例。
86 40
|
5月前
|
设计模式 数据库连接 PHP
PHP中的设计模式:提升代码的可维护性与扩展性在软件开发过程中,设计模式是开发者们经常用到的工具之一。它们提供了经过验证的解决方案,可以帮助我们解决常见的软件设计问题。本文将介绍PHP中常用的设计模式,以及如何利用这些模式来提高代码的可维护性和扩展性。我们将从基础的设计模式入手,逐步深入到更复杂的应用场景。通过实际案例分析,读者可以更好地理解如何在PHP开发中应用这些设计模式,从而写出更加高效、灵活和易于维护的代码。
本文探讨了PHP中常用的设计模式及其在实际项目中的应用。内容涵盖设计模式的基本概念、分类和具体使用场景,重点介绍了单例模式、工厂模式和观察者模式等常见模式。通过具体的代码示例,展示了如何在PHP项目中有效利用设计模式来提升代码的可维护性和扩展性。文章还讨论了设计模式的选择原则和注意事项,帮助开发者在不同情境下做出最佳决策。
|
25天前
|
设计模式 关系型数据库
「全网最细 + 实战源码案例」设计模式——简单工厂模式
简单工厂模式是一种创建型设计模式,通过工厂类根据传入参数创建不同类型的对象,也称“静态工厂方法”模式。其结构包括工厂类、产品接口和具体产品类。优点是封装性强、代码复用性好;缺点是扩展性差,增加新产品时需修改工厂类代码,违反开闭原则。适用于对象种类较少且调用者无需关心创建细节的场景。
53 19
|
23天前
|
设计模式 Java
「全网最细 + 实战源码案例」设计模式——生成器模式
生成器模式(Builder Pattern)是一种创建型设计模式,用于分步骤构建复杂对象。它允许用户通过控制对象构造的过程,定制对象的组成部分,而无需直接实例化细节。该模式特别适合构建具有多种配置的复杂对象。其结构包括抽象建造者、具体建造者、指挥者和产品角色。适用于需要创建复杂对象且对象由多个部分组成、构造过程需对外隐藏或分离表示与构造的场景。优点在于更好的控制、代码复用和解耦性;缺点是增加复杂性和不适合简单对象。实现时需定义建造者接口、具体建造者类、指挥者类及产品类。链式调用是常见应用方式之一。
50 12

热门文章

最新文章