接口分離原則
在面向對象編程中，接口是一個非常重要的武器。接口所表達的是客戶端代碼需求和需求具體實現之間的邊界。接口分離原則主張接口應該足夠小，大而全的契約（接口）是毫無意義的。
接口分離的原因
將大型接口分割為多個小型接口的原因有：
①需要單獨修飾接口
②客戶端需要
③架構需要
需要單獨修飾接口
我們通過拆解一個單個巨型接口到多個小型接口的示例，分離過程中創建了各種各樣的修飾器，來講解大量應用接口分離原則帶來的主要好處。
下面這個接口包含了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#敏捷開發實踐》
