接口分离原则
在面向对象编程中，接口是一个非常重要的武器。接口所表达的是客户端代码需求和需求具体实现之间的边界。接口分离原则主张接口应该足够小，大而全的契约（接口）是毫无意义的。
接口分离的原因
将大型接口分割为多个小型接口的原因有：
①需要单独修饰接口
②客户端需要
③架构需要
需要单独修饰接口
我们通过拆解一个单个巨型接口到多个小型接口的示例，分离过程中创建了各种各样的修饰器，来讲解大量应用接口分离原则带来的主要好处。
下面这个接口包含了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方法从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接口
public class UserSettingsConfig : IUserSettings
=>
public class UserSettingsConfig: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#敏捷开发实践》
