美文网首页工作生活
设计模式 -- 依赖倒置原则

设计模式 -- 依赖倒置原则

作者: 皆为序幕_ | 来源:发表于2019-07-05 16:38 被阅读0次

表述(面向接口编程)

“针对接口编程,不要针对实现编程”就是依赖倒转原则的最好体现:接口(也可以是抽象类)就是一种抽象,只要不修改接口声明,大家可以放心大胆调用,至于接口的内部实现则无需关心,可以随便重构。这里,接口就是抽象,而接口的实现就是细节

抽象指的是委托/协议,细节就是具体的实现类,使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给它们的实现类去完成

优点

代码结构清晰,维护容易

问题提出与解决

类A直接依赖类B,假如需要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险

遵循依赖倒置原则,将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率

示例

需求V1:类SalaryManage(类似上面说的类A)负责工资的管理;Staff(类似上面说的类B)是职员类,现在要通过SalaryManage类来给职员发放工资了

class Staff{
    var name:String
    
    init(name:String) {
        self.name = name
    }
    
    func calculateSalary() {
        print("\(name)的工资是100")
    }
}

class SalaryManage{
    func calculateSalary(stasff:Staff) {
        stasff.calculateSalary()
    }
}

let salary = SalaryManage()
let staff = Staff.init(name: "职员")
salary.calculateSalary(stasff: staff)  //职员的工资是100

需求V2:现在假设需要给经理发工资,发现工资管理类SalaryManage没法直接完成这个功能,需要我们添加新的方法,才能完成,那么只能去修改SalaryManage类来满足业务的需求。产生这种现象的原因就是SalaryManage与Staff之间的耦合性太高了,必须降低它们之间的耦合度才行。因此我们引入一个委托EmployeeProtocol,它提供一个发放工资的方法定义

protocol EmployeeProtocol{
    func calculateSalary()
}

class SalaryManage{
    func calculateSalary(employee:EmployeeProtocol) {
        employee.calculateSalary()
    }
}

class Staff:EmployeeProtocol{
    var name:String
    
    init(name:String) {
        self.name = name
    }
    
    func calculateSalary() {
        print("\(name)的工资是100")
        
    }
    
}

class Manager:EmployeeProtocol{
    var name:String
    
    init(name:String) {
        self.name = name
    }
    
    func calculateSalary() {
        print("\(name)的工资是1000")
    }
}

let salary = SalaryManage()
let staff = Staff.init(name: "职员")
let manager = Manager.init(name: "经理")
salary.calculateSalary(employee: staff)  //  职员的工资是100
salary.calculateSalary(employee: manager)  // 经理的工资是1000

采用依赖倒置原则给多人并行开发带来了极大的便利,比如在上面的例子中,刚开始SalaryManage类与Staff类直接耦合时,SalaryManage类必须等Staff类编码完成后才可以进行编码和测试,因为SalaryManage类依赖于Staff类。按照依赖倒置原则修改后,则可以同时开工,互不影响,因为SalaryManage与Staff类一点关系也没有,只依赖于协议EmployeeProtocol。参与协作开发的人越多、项目越庞大,采用依赖导致原则的意义就越重大

参考:https://www.cnblogs.com/LeeGof/p/5704543.html

相关文章

  • 依赖倒置原则

    个人博客原文:依赖倒置原则 设计模式六大原则之三:依赖倒置原则。 简介 姓名 :依赖倒置原则 英文名 :Depen...

  • 设计模式笔记汇总

    目录 设计原则 “依赖倒置”原则 未完待续... 设计模式 设计模式——策略模式 设计模式——装饰者模式 设计模式...

  • 设计模式——“依赖倒置”原则

    目录 查看其它设计模式笔记,点这里→设计模式笔记汇总 依赖倒置原则(Dependence Inversion Pr...

  • 设计模式的设计原则

    设计模式的设计原则 面向对象五大设计原则 单一职责原则 里氏替换原则 依赖倒置原则 接口隔离原则 开闭原则 设计模...

  • 软件架构设计原则之依赖倒置原则

    1 依赖倒置原则 依赖倒置原则(Dependence Inversion Principle,DIP)是指设计代码...

  • Swift设计模式----目录

    面向对象设计原则: 开闭原则 单一职责原则 依赖倒置原则 接口分离原则 迪米特法则 里氏替换原则 面向对象设计模式...

  • 2022-09-21 依赖倒置

    《设计模式之禅》之依赖倒置原则,Dependence Inversion Principle(DIP),核心就是面...

  • 设计原则之6大原则

    目录:设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置...

  • 设计模式 -- 依赖倒置原则

    表述(面向接口编程) “针对接口编程,不要针对实现编程”就是依赖倒转原则的最好体现:接口(也可以是抽象类)就是一种...

  • 《设计模式》——依赖倒置原则

    先扯两句 很久没有写设计模式了,依赖倒置原则其实在前两篇发完之后,其实就写了一部分,只是后来由于一些例子的贴切程度...

网友评论

    本文标题:设计模式 -- 依赖倒置原则

    本文链接:https://www.haomeiwen.com/subject/jzxdhctx.html