zoukankan      html  css  js  c++  java
  • 设计原则之面向接口编程

    将低层(即没有复杂逻辑的)东西抽象出来当接口,让其去和高层发生关系。


    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

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

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

             依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。

       依赖倒置原则的核心思想是面向接口编程,我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的,母亲给孩子讲故事,只要给她一本书,她就可以照着书给孩子讲故事了。

         运行良好,假如有一天,需求变成这样:不是给书而是给一份报纸,让这位母亲讲一下报纸上的故事。

       这位母亲却办不到,因为她居然不会读报纸上的故事,这太荒唐了,只是将书换成报纸,居然必须要修改Mother才能读。假如以后需求换成杂志呢?换成网页呢?还要不断地修改Mother,这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了,必须降低他们之间的耦合度才行。我们引入一个抽象的接口IReader。读物,只要是带字的都属于读物。

       Mother类与接口IReader发生依赖关系,而Book和Newspaper都属于读物的范畴,他们各自都去实现IReader接口,这样就符合依赖倒置原则了,代码为:


    IRead.h

    @interface IRead : NSObject
    -(void)look;
    @end

    IRead.m

    #import "IRead.h"
    
    @implementation IRead
    -(void)look
    {
        NSLog(@"妈妈开始了。。。。");
    }
    @end

    Book.h

    #import "IRead.h"
    
    @interface Book : IRead
    
    @end

    Book.m

    #import "Book.h"
    
    @implementation Book
    -(void)look
    {
        [super look];
        NSLog(@"很久很久以前有一个阿拉伯的故事……");
    }
    @end

    Newspaper.h

    #import "IRead.h"
    
    @interface Newspaper : IRead
    
    @end

    Newspaper.m

    #import "Newspaper.h"
    
    @implementation Newspaper
    -(void)look
    {
        [super look];
        NSLog(@"林书豪17+9助火箭击败老鹰……");
    }
    @end

    Mother.h

    @interface Mother : NSObject
    
    -(void)read;
    @end

    Mother.m

    #import "Mother.h"
    #import "IRead.h"
    #import "Book.h"
    #import "Newspaper.h"
    @implementation Mother
    -(void)read
    {
        IRead *readBook = [[Book alloc]init];
        IRead *readNewspaper = [[Newspaper alloc]init];
        
        [readBook look];
        [readNewspaper look];
    }
    @end

    AppDelegate.m

    #import "AppDelegate.h"
    #import "Mother.h"
    @implementation AppDelegate
    
    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
    {
        self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
        // Override point for customization after application launch.
        self.window.backgroundColor = [UIColor whiteColor];
        Mother *m = [[Mother alloc]init];
        [m read];
        
        [self.window makeKeyAndVisible];
        return YES;
    }

    这样修改后,无论以后怎样扩展Client类,都不需要再修改Mother类了。这只是一个简单的例子,实际情况中,代表高层模块的Mother类将负责完成主要的业务逻辑,一旦需要对它进行修改,引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性,提高系统的稳定性,降低修改程序造成的风险。

        采用依赖倒置原则给多人并行开发带来了极大的便利,比如上例中,原本Mother类与Book类直接耦合时,Mother类必须等Book类编码完成后才可以进行编码,因为Mother类依赖于Book类。修改后的程序则可以同时开工,互不影响,因为MotherBook类一点关系也没有。参与协作开发的人越多、项目越庞大,采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。

             传递依赖关系有三种方式,以上的例子中使用的方法是接口传递,另外还有两种传递方式:构造方法传递setter方法传递,相信用过Spring框架的,对依赖的传递方式一定不会陌生。
    在实际编程中,我们一般需要做到如下3点:

    • 低层模块尽量都要有抽象类或接口,或者两者都有。
    • 变量的声明类型尽量是抽象类或接口。
    • 使用继承时遵循里氏替换原则。

            依赖倒置原则的核心就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。

  • 相关阅读:
    设计模式(十八)备忘录模式
    六种常见的系统架构
    设计模式(十七)中介者模式
    设计模式(十六)观察者模式
    设计模式(十五)迭代器模式
    js实现对象深拷贝
    js中for in与for of使用
    在使用一些UI框架的某些组件的时候,,取消事件冒泡
    js开根号,使用二分法迭代
    js逆向递归 一个多维数组根据子节点ID查找所有父节点ID
  • 原文地址:https://www.cnblogs.com/huen/p/3515824.html
Copyright © 2011-2022 走看看