依赖倒置原则(二)

依赖倒置原则就是抽象类和接口在使用时的一些规范和建议,我们的应用上层模块不直接依赖于下层模块,不具体依赖某个类或者对象,而是依赖于某个抽象。

接着上一节的Demo,我们有3个手机的对象。分别是LumiaPhone,Galaxy,ApplePhone,现在我们新增一个Student学生类,学生会使用手机。有可能使用LumiaPhone手机,也有可能使用Galaxy,也有可能使用

ApplePhone,那我们的Student看起来的得实现成这样:

       public class Student
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public void PlayPhone(LumiaPhone lumiaPhone)
        {
            Console.WriteLine($"{Name} use {lumiaPhone.Name}");
        }
        public void PlayApplePhone(ApplePhone applePhone)
        {
            Console.WriteLine($"{Name} use {applePhone.Name}");
        }
        public void PlayGalaxy(Galaxy galaxy)
        {
            Console.WriteLine($"{Name} use {galaxy.Name}");
        }
    }

具体使用时,我们可能会是这样:
先创建一个Student再根据学生使用的某种手机 调用不同的play方法

 LumiaPhone lumiaPhone = new LumiaPhone();
ApplePhone applePhone = new ApplePhone();
Galaxy galaxy = new Galaxy();
Student student = new Student();
student.PlayPhone(lumiaPhone);
student.PlayApplePhone(applePhone);
student.PlayGalaxy(galaxy);

这个时候假设Student旧的手机坏了,换了新的华为手机,那我们新增一个Honor对象

 public class Honor
    {
       public void System()
        {
            Console.WriteLine("Hua Wei Honor");
        }
    }

再修改Student类 新增一个方法

 
        public void PlayHonor(Honor honor)
        {
            Console.WriteLine($"{Name} use {honor.Name}");
        }

使用时

 Honor honor = new Honor();
student.PlayHonor(honor);

手机有太多种类,每次新增对象我们都要在Student中新增方法 在调用处进行手机的实例化,维护起来
非常麻烦,容易出错。不利于扩展,所以我们的Student 不应该依赖于具体的类,而是应该依赖抽象
上一遍提到的BasePhone,我们来改造下代码
Student会变成这样

 
 public class Student
    {
        public int Id { get; set; }
        public string Name { get; set; }

        public void PlayPhone(BasePhone basePhone)
        {
            Console.WriteLine($"{Name} use {basePhone.Name}");
        }
        //public void PlayPhone(LumiaPhone lumiaPhone)
        //{
        //    Console.WriteLine($"{Name} use {lumiaPhone.Name}");
        //}

        //public void PlayApplePhone(ApplePhone applePhone)
        //{
        //    Console.WriteLine($"{Name} use {applePhone.Name}");
        //}

        //public void PlayGalaxy(Galaxy galaxy)
        //{
        //    Console.WriteLine($"{Name} use {galaxy.Name}");
        //}

        //public void PlayHonor(Honor honor)
        //{
        //    Console.WriteLine($"{Name} use {honor.Name}");
        //}
    }

我们的调用处

static void Main(string[] args)

{

{

LumiaPhone lumiaPhone = new LumiaPhone();

ApplePhone applePhone = new ApplePhone();

Galaxy galaxy = new Galaxy();

Honor honor = new Honor();

Student student = new Student();

student.PlayPhone(lumiaPhone);

student.PlayPhone(applePhone);

student.PlayPhone(galaxy);

student.PlayPhone(honor);

//student.PlayPhone(lumiaPhone);

//student.PlayApplePhone(applePhone);

//student.PlayGalaxy(galaxy);

//student.PlayHonor(honor);

}

Console.ReadKey();

}

这个时候感觉Main还是依赖了具体的对象Student,以学生使用honor手机为例

                BasePhone honor = new Honor();
                Student student = new Student();
                student.PlayPhone(honor);

我们新增一个SimpleFactory及接口IPlayPhone

    public static class SimpleFactory
    {
        public static BasePhone CreatePhone()
        {
            return new Honor();
        }
        public static Student CreateStudent()
                {
                    return  new Student();
                }
    }
        
    public interface IPlayPhone
    {
        void PlayPhone(BasePhone basePhone);
    }

那我们的Main方法则变成

 static void Main(string[] args)
        {
            {
                BasePhone honor = SimpleFactory.CreatePhone();
                IPlayPhone student = SimpleFactory.CreateStudent();
                student.PlayPhone(honor);
                //Honor honor = new Honor();
                //Student student = new Student();
                //student.PlayPhone(honor);
                //student.PlayPhone(lumiaPhone);
                //student.PlayApplePhone(applePhone);
                //student.PlayGalaxy(galaxy);
                //student.PlayHonor(honor);
            }
            Console.ReadKey();
        }

我在这个demo SimpleFactory里直接返回了一个对象,项目中是可以通过读取配置文件反射来构造实的
这样只要通过改配置文件 就可以实现学生更换手机的功能,同样通过配置文件 也可以实现 老师使用手机只要我们新增一个Teacher类 实现IPlayPhone接口。其他代码不需要任何改动, 这就是我们原则 依赖抽象或接口 而不应该依赖于具体的细节的好处, 这里学生,老师其实就是上层,而我们的手机则是下层,上层不应该依赖下层 而是应该依赖抽象

时间: 2024-11-03 03:27:53

依赖倒置原则(二)的相关文章

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

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

ASP.NET 设计模式中依赖倒置原则

依赖倒置原则 A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. B.抽象不应该依赖于具体,具体应该依赖于抽象. 依赖倒置原则 A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. B.抽象不应该依赖于具体,具体应该依赖于抽象. 目录 1概述 2意图 3代码实现 4结构图 1概述编辑 所谓依赖倒置原则(Dependence Inversion Principle)就是要依赖于抽象,不要依赖于具体.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现

设计模式六大原则---依赖倒置原则(DIP)

定义 依赖倒置原则(Dependency Inversion Principle) 核心思想:依赖于抽象     具体体现: 体现一:高层模块不应该依赖低层模块.两个都应该依赖抽象. 体现二:抽象不应该依赖细节.细节应该依赖抽象. 依赖倒置原则告诉我们:细节是多变的,而抽象是相对稳定的.所以我们编程的时候要注重抽象的编程,而非细节编程. 实例 1.AGP插槽:主板和显卡之间的关系的抽象.主板和显卡通常是使用AGP插槽来连接的,这样,只要接口适配,不管是主板还是显卡更换,都不是问题. 2.驾照:司

设计模式六大原则之依赖倒置原则

一.概念: 依赖倒置原则英文缩写DIP(Dependence Inversion Principle)原始定义:High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. 翻译过来就三层含义

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

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

读秦小波老师《设计模式之禅》问一-依赖倒置原则

这本<设计模式之禅>得来不易,当时是在CSDN的论坛中向秦小波老师提问有幸获得的.读这种经典书籍不能如读小说,逛十里洋场意在消遣,更多的应该是边读变问,每到重点就应该问为什么.秦小波老师的语言有时幽默,有时又切中要害,引人深思.对于"倒置"秦小波老师是从人的思维层面解读的,生活中,例如张三就依赖他家的宝马上下班,也许可以更具体到BMW 740Li,然后回归到程序中,如果我们这样去构建依赖关系,那么如果哪天张三发达了,换了玛莎拉蒂,那是不是整个程序都得改,这个时候我们可以让张

学习设计模式 - 六大基本原则之依赖倒置原则

设计模式总共有六大基本原则,统称为SOLID (稳定)原则,分别是S-单一职责原则(Single Responsibility Principle), O-开闭原则(Open closed Principle),L-里氏替换原则(Liskov Substitution Principle),L-迪米特法则(Law of Demeter),I-接口隔离原则(Interface Segregation Principle),D-依赖倒置原则(Dependence Invension Principl

C#编程:依赖倒置原则DIP

一.前言 我们先来看看传统的三层架构,如下图所示: 从上图中我们可以看到:在传统的三层架构中,层与层之间是相互依赖的,UI层依赖于BLL层,BLL层依赖于DAL层.分层的目的是为了实现“高内聚.低耦合”.传统的三层架构只有高内聚没有低耦合,层与层之间是一种强依赖的关系,这也是传统三层架构的一种缺点.这种自上而下的依赖关系会导致级联修改,如果低层发生变化,可能上面所有的层都需要去修改,而且这种传统的三层架构也很难实现团队的协同开发,因为上层功能取决于下层功能的实现,下面功能如果没有开发完成,则上层

设计模式六大原则: 老板是如何减轻负担的 -- 依赖倒置原则

很多创业公司都对外宣称"扁平化管理",什么是"扁平化管理"呢?请看下面这张架构图: 因为人少,老板直接管理着采购.销售.人力跟 IT 等人员,虽然累了点,但部门少.人不多也还好. 但是随着公司规模发展,每次新加入人员老板都要去认识.沟通,出现问题还得去约出去喝个茶,老板发现自己的时间都浪费在这些琐事,容易耽搁事不说,还发挥不出更大价值. 这时他决定招一些经理替自己分别管理各个部门,自己只要管理这些经理就好了. 于是新的架构图是这样的: 老板这下子省心多了,有问题直接