依赖倒置(Dependence Inversion Principle)DIP

using System;
using System.Collections.Generic;
using System.Text;

namespace DependenceInversionPrinciple
{
    //依赖倒置(Dependence Inversion Principle)DIP
    //High level modules should not depend upon low level modeules.Both should depend upon abstractions.Abstractions should not depend upon details. Details shoudl depend upon abstractions.
    //(1)模块间的依赖通过抽象发生,实现类直接不发生直接的依赖关系,其依赖关系是通过接口或者抽象类产生的。
    //(2)接口或抽象类不依赖于实现类
    //(3)实现类依赖接口或抽象类。
    //OOD(Object-Oriented Design)面向接口编程精髓之一。
    class Program
    {
        static void Main(string[] args)
        {
            //模拟这么一个场景,司机开车遇到查车情况。
            Driver driver = new Driver("小李");
            Benz benz = new Benz();
            BMW bmw = new BMW();
            //多亏了依赖倒置,这样不用在Drive函数里每次针对不同的车型写一个方法,因为它们都是车子,开起来其实是一样的,管他什么牌子。
            driver.Drive(benz);
            //换一辆车开
            driver.Drive(bmw);

            //这时遇到了交警,查车,千万别酒驾哟!
            CheckLicense(driver);
        }

        //这里使用IC1,而没有使用Driver类来做参数类,是因为交警只关注你的驾照情况,如果使用Driver类,会暴露过多的方法和属性,照成不必要的耦合风险。
        static void CheckLicense(IC1 c1)
        {
            c1.ShowInfo();
        }
    }

    //C1驾照接口,有了驾照的人,肯定都可以开小汽车了,不管你的职业是不是司机,这是一个共同的“行为”。
    public interface IC1
    {
        void ShowInfo();
        void Drive(Car car);

    }

    public class Driver : IC1
    {
        public Driver(string name)
        {
            this.Name = name;
        }

        private string name;

        public string Name
        {
            get { return name; }
            set { name = value; }
        }

        public void Drive(Car car)
        {
            car.Start();
            car.Stop();
        }

        public void ShowInfo()
        {
            Console.WriteLine(this.Name + "的驾照是C1驾照");
        }
    }

    //抽象车子,肯定有启动和停止,至于不同车子实现方式不同,抽象出来,给子类实现。
    //为什么不使用接口?这需要关注业务情况进行抽象设计,如果该业务方法涉及到其他的交通工具,如自行车,这个时候用接口,能增强扩展性,扩展一个自行车类,继承接口即可使用。
    //但是这里没有涉及到,仅专注于小汽车,所以抽象类即可。
    public abstract class Car
    {
        private string brand;

        public string Brand
        {
            get { return brand; }
            set { brand = value; }
        }

        public abstract void Start();

        public abstract void Stop();

    }

    public class BMW : Car
    {
        public BMW()
        {
            this.Brand = "宝马";
        }

        public override void Start()
        {
            Console.WriteLine(this.Brand + "汽车启动");
        }

        public override void Stop()
        {
            Console.WriteLine(this.Brand + "汽车停止");
        }
    }

    public class Benz : Car
    {
        public Benz()
        {
            this.Brand = "奔驰";
        }

        public override void Start()
        {
            Console.WriteLine(this.Brand + "汽车启动");
        }

        public override void Stop()
        {
            Console.WriteLine(this.Brand + "汽车停止");
        }
    }
}
时间: 2024-10-08 15:16:40

依赖倒置(Dependence Inversion Principle)DIP的相关文章

依赖倒置原则(Dependence Inversion Principle,DIP)

依赖倒置原则: A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. B.抽象不应该依赖于具体,具体应该依赖于抽象. 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现

设计模式原则(3)--Dependency Inversion Principle(DIP)--依赖倒转原则

1.定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 抽象不应该依赖于细节,细节应当依赖于抽象.换言之,要针对接口编程,而不是针对实现编程. 2.使用场景: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险.即将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C

依赖倒置原则(Dependence Inversion Principle)

高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. 抽象不应该依赖于具体,具体应该依赖于抽象. 简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合.

Dependence Inversion Principle

设计原则之依赖反转原则 动机:当类里面含有属性类,如果直接写类,代码太死,可以考虑将属性类变成接口,方便扩展. 结论:高级类不直接使用低级类,使用接口作为抽象层.Creational Design Patterns可以帮助我们实现依赖反转原则,比如工厂模式,抽象工厂模式,原型模式. Bad Example: 缺点: 1.当出现一个新的工人superWorker,不得不修改Manager的源代码 2.Manger里面已经存在的代码也会被影响,比如方法里面用到Worker class Worker 

依赖倒置原则

What Dependence Inversion Principle(DIP):高层模块不应该依赖底层模块,都应该依赖于抽象:抽象不应该依赖于具体,具体依赖于抽象 Why 若高层依赖于底层,那么底层的变动也会导致高层的变动,这就会导致模块的复用性降低而且大大提高了开发的成本.若是依赖于抽象的话,那么是比较稳定的,底层或者高层的变动都不会互相影响. How 很多地方引用的个人觉得也非常有代表性的一个例子:公司是福特和本田公司的金牌合作伙伴,现要求开发一套自动驾驶系统,只要汽车上安装该系统就可以实

对依赖倒置原则(DIP)及Ioc、DI、Ioc容器的一些理解

.概述 所谓依赖倒置原则(Dependence Inversion Principle)就是要依赖于抽象,不要依赖于具体.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合,并由此引申出IoC.DI以及Ioc容器等概念. 2.意图 面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变动时上层也要跟着变动,这就会导致模块的复用性降低而且大大提高了开发的成本. 面向对象的开发很好的解决了这个问题,一般情况下抽象的变化概率很小,让用户程序依赖于抽象,实现的细节

对依赖倒置原则(DIP)及Ioc、DI、Ioc容器的一些理解(转)

所谓依赖倒置原则(Dependence Inversion Principle)就是要依赖于抽象,不要依赖于具体.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合,并由此引申出IoC.DI以及Ioc容器等概念. 面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变动时上层也要跟着变动,这就会导致模块的复用性降低而且大大提高了开发的成本. 面向对象的开发很好的解决了这个问题,一般情况下抽象的变化概率很小,让用户程序依赖于抽象,实现的细节也依赖于抽象.即使

C#软件设计——小话设计模式原则之:依赖倒置原则DIP

前言:很久之前就想动笔总结下关于软件设计的一些原则,或者说是设计模式的一些原则,奈何被各种bootstrap组件所吸引,一直抽不开身.群里面有朋友问博主是否改行做前端了,呵呵,其实博主是想做“全战”,即各方便都有战斗力.关于设计模式,作为程序猿的我们肯定都不陌生.博主的理解,所谓设计模式就是前人总结下来的一些对于某些特定使用场景非常适用的优秀的设计思路,“前人栽树,后人乘凉”,作为后来者的我们就有福了,当我们遇到类似的应用场景的时候就可以直接使用了.关于设计模式的原则,博主将会在接下来的几篇里面

Java 设计模式(十二) 依赖倒置原则(DIP)

依赖倒置原则(Dependence Inversion Principle) 依赖倒置原则(DIP)的基本概念 原始定义 高层模块不应该依赖低层模块,两者都应该依赖其抽象 抽象不应该依赖细节 细节应该依赖抽象 Java中的具体含义 模块间的依赖通过抽象发生 实现类之间不发生直接的依赖关系 其依赖关系通过接口或者抽象类产生 接口或抽象类不依赖于具体实现 实现类依赖接口或抽象类 依赖倒置(DIP)的好处 采用DIP可以减少类之间的耦合性,提高稳定性,降低并行开发带来的风险,提高代码的可读性和可维护性