image.png
接口隔離原則（Interface Segregation Principle, ISP）是SOLID設(shè)計原則中的第四個原則驹马。它主張不應(yīng)該強迫客戶依賴于它們不使用的方法革砸，即一個類對另一個類的依賴應(yīng)該建立在最小的接口上。
肖哥彈架構(gòu) 跟大家“彈彈” 代碼設(shè)計技巧糯累，需要代碼關(guān)注
歡迎 點贊算利，點贊，點贊泳姐。
關(guān)注公號Solomon肖哥彈架構(gòu)獲取更多精彩內(nèi)容
歷史熱點文章
- 數(shù)據(jù)訪問對象模式（Data Access Object Pattern）：電商平臺商品管理實戰(zhàn)案例分析
- Holder模式（Holder Pattern）：公司員工權(quán)限管理系統(tǒng)實戰(zhàn)案例分析
- 一個項目代碼講清楚DO/PO/BO/AO/E/DTO/DAO/ POJO/VO
2. 接口隔離設(shè)計圖：
將一個臃腫的接口拆分為多個客戶端特定的接口：
image.png
3. 接口隔離解決什么：
接口隔離原則解決了因為接口設(shè)計過于龐大而導(dǎo)致的低內(nèi)聚和高耦合問題效拭，使得使用接口的類實現(xiàn)了許多它們不需要的方法。
4. 接口隔離特點：
- 接口細(xì)分：接口應(yīng)該盡可能小且職責(zé)單一胖秒。
- 客戶端定制：接口應(yīng)該根據(jù)客戶端的需要定制缎患。
- 高內(nèi)聚：每個接口都聚焦于特定的功能。
- 低耦合：客戶端只依賴于它們需要的接口阎肝。
5. 接口隔離缺點：
- 接口數(shù)量增加：可能會導(dǎo)致接口數(shù)量過多挤渔，管理起來較為復(fù)雜。
- 設(shè)計難度：需要更多的設(shè)計思考來確定合適的接口粒度风题。
6. 接口隔離使用場景：
當(dāng)一個類實現(xiàn)了許多它不需要的方法時判导，或者當(dāng)多個類因為依賴同一個接口而互相影響時，應(yīng)該考慮使用接口隔離原則俯邓。
7.接口隔離案例
7.1 多環(huán)境配置管理案例
考慮一個應(yīng)用骡楼，它需要根據(jù)不同的環(huán)境（開發(fā)熔号、測試稽鞭、生產(chǎn)）加載不同的配置。
重構(gòu)前：
public interface IEnvironmentConfig {
String getDatabaseUrl();
String getAuthServiceUrl();
String getEmailServiceUrl();
}
public class DevEnvironmentConfig implements IEnvironmentConfig {
@Override
public String getDatabaseUrl() {
return "dev_database_url";
}
@Override
public String getAuthServiceUrl() {
// Dev環(huán)境可能不需要認(rèn)證服務(wù)
return "";
}
@Override
public String getEmailServiceUrl() {
return "dev_email_service_url";
}
}
// Prod環(huán)境的配置類...
重構(gòu)后：
public interface IDatabaseConfig {
String getDatabaseUrl();
}
public interface IAuthServiceConfig {
String getAuthServiceUrl();
}
public interface IEmailServiceConfig {
String getEmailServiceUrl();
}
public class DevEnvironmentConfig implements IDatabaseConfig, IEmailServiceConfig {
@Override
public String getDatabaseUrl() {
return "dev_database_url";
}
// DevEnvironmentConfig不實現(xiàn)IAuthServiceConfig引镊，因為它不需要認(rèn)證服務(wù)
}
public class ProdEnvironmentConfig implements IDatabaseConfig, IAuthServiceConfig, IEmailServiceConfig {
@Override
public String getDatabaseUrl() {
return "prod_database_url";
}
@Override
public String getAuthServiceUrl() {
return "prod_auth_service_url";
}
@Override
public String getEmailServiceUrl() {
return "prod_email_service_url";
}
}
public class Application {
private IDatabaseConfig databaseConfig;
private IAuthServiceConfig authServiceConfig;
private IEmailServiceConfig emailServiceConfig;
public Application(IEnvironmentConfig environmentConfig) {
this.databaseConfig = environmentConfig;
// 根據(jù)環(huán)境需求注入其他配置...
}
public void configureServices() {
// 使用注入的配置初始化服務(wù)
}
}
7.2 支付系統(tǒng)集成案例
商務(wù)平臺朦蕴，需要集成多種支付方式篮条，如信用卡支付和銀行轉(zhuǎn)賬
重構(gòu)前：
public interface IPayable {
void processPayment();
}
public class PaymentService {
public void processPayment(IPayable payment) {
payment.processPayment();
}
}
// 特定支付方式實現(xiàn)IPayable接口
public class CreditCardPayment implements IPayable {
@Override
public void processPayment() {
// 處理信用卡支付邏輯
}
}
public class BankTransferPayment implements IPayable {
@Override
public void processPayment() {
// 處理銀行轉(zhuǎn)賬邏輯
}
}
分析問題：
-
過度依賴:
IPayable接口強制所有實現(xiàn)類都實現(xiàn)processPayment方法，但不同支付方式可能需要不同的處理邏輯和附加步驟吩抓，例如信用卡授權(quán)或賬戶驗證涉茧。 -
低內(nèi)聚性:
IPayable接口可能包含了與支付處理無直接關(guān)聯(lián)的方法，導(dǎo)致接口的內(nèi)聚性降低疹娶。 - 擴展性差: 當(dāng)需要添加新的支付方式或改變現(xiàn)有支付邏輯時伴栓，可能需要修改接口定義或?qū)Χ鄠€類進行更改，這增加了擴展的難度雨饺。
- 違反LSP: 如果子類重寫了基類的方法以添加特定邏輯钳垮，這可能會影響使用基類引用的客戶端代碼，違反了里氏替換原則额港。
- 代碼冗余: 為了滿足接口定義饺窿，某些類可能不得不提供空實現(xiàn)或不相關(guān)的實現(xiàn)，導(dǎo)致代碼冗余移斩。
重構(gòu)后：
public interface IPaymentProcessor {
void processPayment();
}
public interface ICreditCardPaymentProcessor extends IPaymentProcessor {
void authorizeCard();
}
public interface IBankTransferPaymentProcessor extends IPaymentProcessor {
void validateAccount();
}
public class CreditCardPaymentProcessor implements ICreditCardPaymentProcessor {
@Override
public void processPayment() {
// 處理信用卡支付邏輯
}
@Override
public void authorizeCard() {
// 授權(quán)信用卡
}
}
public class BankTransferPaymentProcessor implements IBankTransferPaymentProcessor {
@Override
public void processPayment() {
// 處理銀行轉(zhuǎn)賬邏輯
}
@Override
public void validateAccount() {
// 驗證賬戶信息
}
}
public class PaymentService {
public void processPayment(IPaymentProcessor paymentProcessor) {
paymentProcessor.processPayment();
}
}
解決的問題：
-
職責(zé)明確: 通過將
IPayable拆分為IPaymentProcessor肚医、ICreditCardPaymentProcessor和IBankTransferPaymentProcessor，每個接口都聚焦于特定的支付處理職責(zé)向瓷，提高了內(nèi)聚性肠套。 -
更好的擴展性: 新的支付方式可以通過實現(xiàn)相應(yīng)的接口輕松添加，而不影響現(xiàn)有代碼猖任。例如糠排，如果需要添加微信支付，可以創(chuàng)建一個實現(xiàn)
IPaymentProcessor的WeChatPaymentProcessor類超升。 -
遵循LSP: 子類（特定支付處理器）現(xiàn)在可以安全地替換基類（
IPaymentProcessor）入宦，而不改變客戶端代碼的行為，因為它們提供了與基類相同的方法室琢。 - 減少代碼冗余: 每個支付處理器類只需要實現(xiàn)與其職責(zé)相關(guān)的接口方法乾闰，消除了不必要的空實現(xiàn)或不相關(guān)的方法。
- 靈活性增強: 通過分離接口盈滴，可以更靈活地組合不同的支付處理步驟涯肩，例如，可以在信用卡支付處理器中添加額外的授權(quán)步驟巢钓，而不會影響到其他支付方式病苗。
- 易于維護: 當(dāng)需要修改特定支付方式的邏輯時，只需修改對應(yīng)的接口實現(xiàn)症汹，而不會影響到其他支付方式的實現(xiàn)硫朦，簡化了維護工作。
8. 參考開源框架：
- 在Java的Spring框架中背镇，接口通常被設(shè)計得非常小且職責(zé)單一咬展，以確保它們可以被客戶端類輕松實現(xiàn)泽裳，而不會引入不必要的依賴。
- 在Spring框架中破婆，通過使用Profile來區(qū)分不同環(huán)境的配置涮总，體現(xiàn)了接口隔離原則。
9. 總結(jié)：
接口隔離原則是提高軟件系統(tǒng)可維護性和靈活性的關(guān)鍵原則祷舀。通過將大型接口拆分為更小的瀑梗、特定于客戶端的接口，我們減少了客戶端類與它們不使用的接口方法之間的不必要耦合裳扯。雖然這可能會導(dǎo)致接口數(shù)量的增加夺克，但它為構(gòu)建一個更加模塊化和可擴展的系統(tǒng)提供了堅實的基礎(chǔ)。遵循接口隔離原則有助于確保每個接口都緊湊且職責(zé)明確嚎朽，從而簡化了代碼的理解和維護铺纽。
歷史熱點文章
- 享元模式（Flyweight Pattern）：網(wǎng)頁游戲中的角色對象管理實戰(zhàn)案例分析
- 觀察者模式（Observer Pattern）：股票交易系統(tǒng)實戰(zhàn)案例分析
- 策略模式（Strategy Pattern）：電商平臺的優(yōu)惠券系統(tǒng)實戰(zhàn)案例分析
- 模板方法模式（Template Method Pattern）:視頻播放應(yīng)用實戰(zhàn)案例分析
- 命令模式（Command Pattern）:網(wǎng)絡(luò)爬蟲任務(wù)隊列實戰(zhàn)案例分析
- 迭代器模式（Iterator Pattern）：電商平臺商品分類瀏覽實戰(zhàn)案例分析
- 中介者模式（Mediator Pattern）:即時通訊軟件實戰(zhàn)案例分析
- 備忘錄模式（Memento Pattern）:游戲存檔系統(tǒng)實戰(zhàn)案例分析
- 狀態(tài)模式（State Pattern）:電商平臺訂單狀態(tài)管理實戰(zhàn)案例分析
- 責(zé)任鏈模式（Chain of Responsibility Pattern）：電商平臺的訂單審批流程實戰(zhàn)案例分析
- 訪問者模式（Visitor Pattern）:電商平臺商品訪問統(tǒng)計實戰(zhàn)案例分析
- 工廠方法模式（Factory Method Pattern）: 電商多種支付實戰(zhàn)案例分析
- 抽象工廠模式（Abstract Factory Pattern）：多風(fēng)格桌面應(yīng)用實戰(zhàn)案例分析
- 建造者模式（Builder Pattern）： 在線訂單系統(tǒng)實戰(zhàn)案例分析
- 原型模式（Prototype Pattern）: 云服務(wù)環(huán)境配置實戰(zhàn)案例分析
- 適配器模式（Adapter Pattern）:第三方支付集成實戰(zhàn)案例分析
- 裝飾器模式（Decorator Pattern）:電商平臺商品價格策略實戰(zhàn)案例分析
- 單例模式（Singleton Pattern）：購物車實戰(zhàn)案例分析
