美文网首页模式敏捷开发程序员
聊聊设计模式原则(三) -- 依赖倒置原则

聊聊设计模式原则(三) -- 依赖倒置原则

作者: CatchZeng | 来源:发表于2018-06-02 15:19 被阅读12次

    目录

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

    定义

    • 高层模块不应该依赖低层模块,二者都应该依赖其抽象;
    • 抽象不应该依赖细节;
    • 细节应该依赖抽象。
    也就是说高层模块,低层模块,细节都应该依赖抽象

    由来

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

    由来

    解决方案

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

    解决方案

    优点

    依赖倒置原则可以减少类间的耦合性,提高系统的稳定,降低并行开发引起的风险,提高代码的可读性和可维护性。

    思考

    1.依赖倒置原则跟面向接口编程是什么关系?

    依赖倒置原则的核心思想就是面向接口编程

    2.什么是细节?什么是抽象?他们有什么区别?

    所谓细节就是较为具体的东西,比如具体的类,就如上面的类B与类C,有具体的实现。

    所谓抽象就是具有契约性、共同性、规范性的表达,比如上面的接口I。它表达了一种契约--你需要实现funcA和funcB才能被当成I来对待。

    相对于细节的多变性,抽象的东西要稳定的多。
    以上面的类ABC作为例子,B、C类都属于细节,如果A直接依赖B或者C,那么B或C的改动有可能就会影响到A的稳定性。同样的,A对B或者C的操作也有可能影响到B或C的稳定性。这些互相影响,其实来源于直接的依赖,导致B或C的细节暴露过多。而面对抽象的接口I,A只能操作funA和funcB,从而避免了不必要的暴露和风险。

    以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。
    稳定性表现在规范性、契约性、易修改性、扩展性、可维护性等。

    来个栗子

    小明(程序员)接到小李(产品经理)的需求:
    客户端开始的时候打个“开始”的log。
    小明心想简单,一下子完成了代码

    public class Logger {
        func log(_ text: String) {
            print(text)
        }
    }
    
    public class Client {
        public var logger: Logger?
    
        func start() {
            logger?.log("开始")
        }
    }
    
    let client = Client()
    let logger = Logger()
    client.logger = logger
    
    client.start()
    

    这个时候,小李突然说,要把log变成存到文件的形式。
    小明想了下,有点不情愿地改了代码(因为要改好几个地方)

    public class FileLogger { //修改1
        func log(_ text: String) {
            writeTofile(text) //修改2
        }
        
        func start() {
            print("开始")
        }
    }
    
    public class Client {
        public var logger: FileLogger? //修改3
    
        func start() {
            logger.start()
            logger?.log("开始")
        }
    }
    
    let client = Client()
    let logger = FileLogger() //修改4
    client.logger = logger
    
    client.start()
    

    小李想了想现在是互联网时代,还是直接将log信息传到网络上吧。
    这个时候,小明非常不情愿地说了声“你不早说”,但还是改了代码(又是好几处改动)

    public class WebLogger { //修改1
        func log(_ text: String) {
            writeToWeb(text) //修改2
        }
    }
    
    public class Client {
        public var logger: WebLogger? //修改3
    
        func start() {
            logger?.log("开始")
        }
    }
    
    let client = Client()
    let logger = WebLogger() //修改4
    client.logger = logger
    
    client.start()
    

    这时,小明的老大小华看到小明不开心,便过来帮忙,改了下代码

    protocol Logger {
        func log(_ text: String)
    }
    
    public class WebLogger: Logger {
        func log(_ text: String) {
            writeToWeb(text) 
        }
    }
    
    public class FileLogger: Logger {
        func log(_ text: String) {
            writeTofile(text) 
        }
    }
    
    public class PrintLogger: Logger {
        func log(_ text: String) {
            print(text)
        }
    }
    
    public class Client {
        public var logger: Logger? 
    
        func start() {
            logger?.log("开始")
        }
    }
    
    let client = Client()
    let logger = WebLogger()
    client.logger = logger
    
    client.start()
    

    小华对小明说,现在不用怕了,小李想什么样的log你改一下实现类就行了

    let logger = WebLogger() // PrintLogger()  FileLogger()
    

    小华的改动其实就是利用了依赖倒置原则,增强了易修改性、扩展性、可维护性等。
    细心的朋友其实还发现了,在改成FileLogger的时候,Client多余地调用了FileLogger的start方法。这就是依赖细节,暴露细节,引起的问题。而使用抽象的接口就能较好地避免这类问题。

    注意点

    • 分清细节与抽象
      虽然依赖倒置原则有很大的好处,但也不是所有的类都需要有抽象一个接口去对应,要视情况而定。

    • 变量的声明类型尽量是抽象类或接口
      注意是尽量,而不是全部。

    • 尽量不要覆写基类的方法
      如果基类是一个抽象类,而这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会有一定的影响。

    • 继承要遵循里氏替换原则

    相关文章

      网友评论

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

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