编码最佳实践——接口分离原则

接口分离原则

在面向对象编程中,接口是一个非常重要的武器。接口所表达的是客户端代码需求和需求具体实现之间的边界。接口分离原则主张接口应该足够小,大而全的契约(接口)是毫无意义的。

接口分离的原因

将大型接口分割为多个小型接口的原因有:

①需要单独修饰接口

②客户端需要

③架构需要

需要单独修饰接口

我们通过拆解一个单个巨型接口到多个小型接口的示例,分离过程中创建了各种各样的修饰器,来讲解大量应用接口分离原则带来的主要好处。

下面这个接口包含了5个方法,用于用户对实体对象的持久化存储进行CRUD操作。

public interface ICreateReadUpdateDelete<TEntity>
{
    void Create(TEntity entity);
    TEntity ReadOne(Guid identity);
    IEnumerable<TEntity> ReadAll();
    void Update(TEntity entity);
    void Delete(TEntity entity);
}

ICreateReadUpdateDelete是一个泛型接口,可以接受不同的实体类型。客户端需要首先声明自己要依赖的TEntity。CRUD中的每个操作都是由对应的ICreateReadUpdateDelete接口实现来执行,也包括修饰器实现。

有些修饰器作用于所有方法,比如日志修饰器。当然,日志修饰器属于横切关注点,为了避免在多个接口中重复实现,也可以使用面向切面编程(AOP)来修饰接口的所有实现。

public class CrudLogging<TEntity> : ICreateReadUpdateDelete<TEntity>
{
    private readonly ICreateReadUpdateDelete<TEntity> decoratedCrud;
    private readonly ILog log;
    public CrudLogging(ICreateReadUpdateDelete<TEntity> decoratedCrud,
         ILog log)
    {
        this.decoratedCrud = decoratedCrud;
        this.log = log;
    }

    public void Create(TEntity entity)
    {
        log.InfoFormat("Create entity of type {0}", typeof(TEntity).Name);
        decoratedCrud.Create(entity);
    }

    public void Delete(TEntity entity)
    {
        log.InfoFormat("Delete entity of type {0}", typeof(TEntity).Name);
        decoratedCrud.Delete(entity);
    }

    public IEnumerable<TEntity> ReadAll()
    {
        log.InfoFormat("Reading all entities of type {0}", typeof(TEntity).Name);
        return decoratedCrud.ReadAll();
    }

    public TEntity ReadOne(Guid identity)
    {
        log.InfoFormat("Reading  entity of type {0}", typeof(TEntity).Name);
        return decoratedCrud.ReadOne(identity);
    }

    public void Update(TEntity entity)
    {
        log.InfoFormat("Update  entity of type {0}", typeof(TEntity).Name);
        decoratedCrud.Update(entity);
    }
}

但是有些修饰器只应用于接口的部分方法上,而不是所有的方法。假设现在有这么一个需求,在持久化存储中删除某个实体前提示用户。切记不要直接去修改现有的类实现,因为这会违背开放与封闭原则。相反,应该创建一个客户端用来删除实体的新实现。

public class DeleteConfirm<TEntity> : ICreateReadUpdateDelete<TEntity>
 {
     private readonly ICreateReadUpdateDelete<TEntity> decoratedCrud;
     public DeleteConfirm(ICreateReadUpdateDelete<TEntity> decoratedCrud)
     {
         this.decoratedCrud = decoratedCrud;
     }
     public void Create(TEntity entity)
     {
         decoratedCrud.Create(entity);
     }

     public IEnumerable<TEntity> ReadAll()
     {
         return decoratedCrud.ReadAll();
     }

     public TEntity ReadOne(Guid identity)
     {
         return decoratedCrud.ReadOne(identity);
     }

     public void Update(TEntity entity)
     {
         decoratedCrud.Update(entity);
     }

     public void Delete(TEntity entity)
     {
         Console.WriteLine("Are you sure you want to delete the entity ? [y/n]");
         var keyInfo = Console.ReadKey();
         if(keyInfo.Key == ConsoleKey.Y)
         {
             decoratedCrud.Delete(entity);
         }
     }
 }

如上代码,DeleteConfirm只修饰了Delete方法,其余方法都是直托方法(没有任何修饰,就像直接调用被修饰的接口方法一样)。尽管这些直托方法什么都没有做,你还是需要一一实现,并且还需要编写测试方法验证方法行为是否正确,这样做与接口分离的方式比较起来麻烦的多。

我们可以将Delete方法从ICreateReadUpdateDelete接口分离,这样会得到两个接口:

public interface ICreateReadUpdate<TEntity>
 {
     void Create(TEntity entity);
     TEntity ReadOne(Guid identity);
     IEnumerable<TEntity> ReadAll();
     void Update(TEntity entity);
 }

 public interface IDelete<TEntity>
 {
     void Delete(TEntity entity);
 }

然后只对IDelete接口提供确认修饰器的实现:

public class DeleteConfirm<TEntity> : IDelete<TEntity>
{
    private readonly IDelete<TEntity> decoratedDelete;
    public DeleteConfirm(IDelete<TEntity> decoratedDelete)
    {
        this.decoratedDelete = decoratedDelete;
    }

    public void Delete(TEntity entity)
    {
        Console.WriteLine("Are you sure you want to delete the entity ? [y/n]");
        var keyInfo = Console.ReadKey();
        if(keyInfo.Key == ConsoleKey.Y)
        {
            decoratedDelete.Delete(entity);
        }
    }
}

这样一来,代码意图更清晰,代码量减少了,也没有那么多的直托方法,相应的测试工作量也变少了。

客户端需要

客户端只需要它们需要的东西。那些巨型接口倾向于给用户提供更多的控制能力,带有大量成员的接口允许客户端做很多操作,甚至包括它们不应该做的。更好的办法是尽早采用防御方式进行编程,以此阻止其他开发人员(包括将来的自己)无意中使用你的接口做出一些不该做的事情。

现在有一个场景是通过用户配置接口访问程序当前的主题,实现如下:

public interface IUserSettings
{
    string Theme
    {
        get;
        set;
    }
}
public class UserSettingsConfig : IUserSettings
    {        private const string ThemeSetting = "Theme";        private readonly Configuration config;        public UserSettingsConfig()        {        config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
    }

    public string Theme
        {            get            {                return config.AppSettingd[ThemeSetting].value;            }            set            {            config.AppSettingd[ThemeSetting].value = value;
            config.Save();
            ConfigurationManager.RefreshSection("appSettings");
        }
    }
}

接口不同的客户端以不同的目的使用同一个属性:

public class ReadingController
{
    private readonly IUserSettings userSettings;
    public ReadingController(IUserSettings userSettings)
    {
        this.userSettings = userSettings;
    }

    public string GetTheme()
    {
        return userSettings.Theme;
    }
}

public class WritingController
{
    private readonly IUserSettings userSettings;
    public WritingController(IUserSettings userSettings)
    {
        this.userSettings = userSettings;
    }

    public void SetTheme(string theme)
    {
        userSettings.Theme = theme;
    }
}

虽然现在ReadingController类只是用了Theme属性的读取器,WritingController类只使用了Theme属性的设置器。但是由于缺乏接口分离,我们无法阻止WritingController类获取主题数据,也无法阻止ReadingController类修改主题数据,这可是个大问题,尤其是后者。

为了防止和消除错用接口的可能性,可以将原有接口一分为二:一个负责读取主题数据,一个负责修改主题数据。

public interface IUserSettingsReader
{
    string Theme
    {
        get;
    }
}
public interface IUserSettingsWriter
{
    string Theme
    {
        set;
    }
}

UserSettingsConfig实现类现在分别实现IUserSettingsReader和IUserSettingsWriter接口

publicclassUserSettingsConfig:IUserSettings

=>

publicclassUserSettingsConfig:IUserSettingsReader,IUserSettingsWriter

客户端现在分别只依赖它们真正需要的接口:

public class ReadingController
{
    private readonly IUserSettingsReader userSettings;
    public ReadingController(IUserSettingsReader userSettings)
    {
        this.userSettings = userSettings;
    }

    public string GetTheme()
    {
        return userSettings.Theme;
    }
}

public class WritingController
{
    private readonly IUserSettingsWriter userSettings;
    public WritingController(IUserSettingsWriter userSettings)
    {
        this.userSettings = userSettings;
    }

    public void SetTheme(string theme)
    {
        userSettings.Theme = theme;
    }
}

架构需要

另一种接口分离的驱动力来自于架构设计。在非对称架构中,例如命令查询责任分离模式(读写分离),意图就是指导你去做一些接口分离的动作。

数据库(表)的设计本身是面向数据,面向集合的;而现在的主流编程语言都有面向对象的一面。面向数据(集合)和面向对象本身就是冲突的,但是在现代系统中数据库又是必不可少的一环。为了解决这种阻抗失衡,ORM(对象关系映射)应运而生。完全隔离掉数据库,允许我们像操作对象一样操作数据库。现在一般的做法是,增删改操作使用ORM,查询使用原生SQL。对于查询而言,越简单,越有效率(开发效率和执行效率)最好。

示意图如下:

客户端构建

接口的设计(无论是分离或是其他方式产生的)会影响实现接口的类型以及使用该接口的客户端。如果客户端要使用接口,就必须先以某种方式获得接口实例。为客户端提供接口实例的方式一定程度上取决于接口实现的数目。如果每个接口都有自己特有的实现,那么就需要构造所有的实现的实例并提供给客户端。如果所有接口的实现都包含在单个类中,那么只需要构建该类的实例就能满足客户端的所有依赖。

多实现、多实例

假设IRead、ISave和IDelete接口都有自己的实现类,客户端就需要同时引入这三个接口。这也是我们平常开发中最常用的一种方式,基于组合实现,需要哪个接口就引入对应的接口,类似于一种可插拔的组件式开发。

public class OrderController
{
    private readonly IRead<Order> reader;
    private readonly ISave<Order> saver;
    private readonly IDelete<Order> deleter;

    public OrderController(IRead<Order> reader,
        ISave<Order> saver,
        IDelete<Order> deleter)
    {
        this.reader = reader;
        this.saver = saver;
        this.deleter = deleter;
    }

    public void CreateOrder(Order order)
    {
        saver.Save(order);
    }

    public Order GetOrder(Guid orderID)
    {
        return reader.ReadOne(orderID);
    }

    public void UpdateOrder(Order order)
    {
        saver.Save(order);
    }

    public void DeleteOrder(Order order)
    {
        deleter.Delete(order);
    }
}

单实现、单实例

此种方式是在单个类中继承并实现多个分离的接口,看上去也许有些反常(接口的分离的目的不是再次把它们统一在单个实现中)。常用于接口的叶子实现类,也就是说,既不是修饰器也不是适配器的实现类,而是完成工作的实现类。在叶子实现类上应用这种方式,是因为叶子类中所有实现的上下文是一致的。这种方式经常应用在和Entity Framework等持久化框架直接打交道的类。

public class CreateReadUpdateDelete<TEntity>:
    IRead<TEntity>,ISave<TEntity>,IDelete<TEntity>
{
    public void Save(TEntity entity)
    {

    }
    public IEnumerable<TEntity> ReadAll()
    {
        return new List<TEntity>();
    }
    public void Delete(TEntity entity)
    {

    }
}

public OrderController CreateSingleService()
{
    var crud = new CreateReadUpdateDelete<Order>();
    return new OrderController(crud,crud,crud);
}

超级接口反模式

把所有接口分离得来的接口又聚合在同一个接口下是一个常见的错误,这些接口一起聚合构成了一个“超级接口”,这破坏了接口分离带来的好处。

public interface CreateReadUpdateDelete<TEntity>:
    IRead<TEntity>,ISave<TEntity>,IDelete<TEntity>
{

}

总结

接口分离,无论是用来辅助修饰,还是为客户端隐藏它们不应该看到的功能,还是作为架构设计的产物。我们都应该在创建任何接口时牢记接口分离这个技术原则,而且最好是从一开始就应用接口分离原则。

参考

《C#敏捷开发实践》

-----END-----

原文发布于微信公众号 - CoderFocus(lumanxs)

原文发表时间:2018-10-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

Java线程面试题 Top 50

不管你是新程序员还是老手,你一定在面试中遇到过有关线程的问题。Java语言一个重要的特点就是内置了对并发的支持,让Java大受企业和程序员的欢迎。大多数待遇丰厚...

1052
来自专栏Linyb极客之路

工作流引擎之activiti入门

在解释activiti之前我们看一下什么是工作流。 工作流(Workflow),就是“业务过程的部分或整体在计算机应用环境下的自动化”,它主要解决的是“使在多个...

1.9K4
来自专栏丑胖侠

《Drools7.0.0.Final规则引擎教程》第2章 追溯Drools5的使用

2.1 Drools5简述 上面已经提到Drools是通过规则编译、规则收集和规则的执行来实现具体功能的。Drools5提供了以下主要实现API: Knowl...

3748
来自专栏腾讯Bugly的专栏

【团队分享】刀锋铁骑:常见Android Native崩溃及错误原因

王竞原,负责网游刀锋铁骑项目,高级开发工程师,使用C++已有10年,非常喜欢C++,特别是C++11。希望能与广大的C++爱好者多交流。 一、什么是Androi...

4653
来自专栏扎心了老铁

分布式锁的实现(redis)

1、单机锁 考虑在并发场景并且存在竞态的状况下,我们就要实现同步机制了,最简单的同步机制就是加锁。 加锁可以帮我们锁住资源,如内存中的变量,或者锁住临界区(线程...

3956
来自专栏漏斗社区

点击!AWD攻防解题技巧在此!

背景 这周,给各位带来AWD攻防源码分析。在百越杯CTF比赛中,小学弟通过抓取访问日志得到漏洞利用的方法,于是斗哥决定拿到源码,分析题目的考点,为小伙伴们排忧...

56310
来自专栏程序员的知识天地

这4个Python实战项目,让你瞬间读懂Python!

Python当下真的很火。Python实战项目,也一直尤为关注,接下来,和大家介绍下十个Python练手的实战项目

1143
来自专栏小曾

.Net 如何模拟会话级别的信号量,对http接口调用频率进行限制(有demo)

现在,因为种种因素,你必须对一个请求或者方法进行频率上的访问限制。 比如, 你对外提供了一个API接口,注册用户每秒钟最多可以调用100次,非注册用户每秒钟最...

962
来自专栏Java帮帮-微信公众号-技术文章全总结

回顾Java 8 9 10的新特性,展望即将来临的11和明年的12【大牛经验】

1997年4月2日,JavaOne会议召开,参与者逾一万人,创当时全球同类会议纪录;

1.3K3
来自专栏Golang语言社区

Go语言并发编程总结

Golang :不要通过共享内存来通信,而应该通过通信来共享内存。这句风靡在Go社区的话,说的就是 goroutine中的 channel …….

1354

扫码关注云+社区

领取腾讯云代金券