image.png
依賴倒置原則（Dependency Inversion Principle, DIP）是SOLID原則的一部分践叠，它提倡在設(shè)計時依賴于抽象（接口或抽象類），而不是具體的實現(xiàn)叨恨。這有助于降低模塊間的耦合度柳刮，提高系統(tǒng)的可擴展性和可維護(hù)性。
肖哥彈架構(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. 依賴倒置原則解決什么：
依賴倒置原則解決了在支付網(wǎng)關(guān)設(shè)計中蚕甥，業(yè)務(wù)邏輯層與具體支付實現(xiàn)之間的緊密耦合問題。
4. 依賴倒置原則特點：
- 抽象化依賴：高層模塊依賴于抽象接口栋荸，而不是具體的實現(xiàn)類菇怀。
- 靈活性增強：可以靈活地替換或增加新的支付處理器凭舶，而不影響業(yè)務(wù)邏輯層。
5. 依賴倒置原則缺點：
- 可能增加設(shè)計復(fù)雜性：需要更多的接口定義和實現(xiàn)類爱沟。
- 性能考慮：間接層可能對性能有一定影響帅霜，尤其是在高性能要求的場景下。
6. 依賴倒置原則使用場景：
- 當(dāng)系統(tǒng)需要支持多種支付方式呼伸，并且預(yù)期會引入更多支付方式或修改現(xiàn)有支付邏輯時义屏。
- 在ERP系統(tǒng)中，當(dāng)需要從多個數(shù)據(jù)源生成報告蜂大，或預(yù)期報告生成方式將隨時間變化時闽铐。
7. 依賴倒置原則案例
7.1 支付網(wǎng)關(guān)案例
重構(gòu)前：
public class PaymentGateway {
public PaymentResponse processPayment(PaymentDetails details) {
// 直接使用具體的支付處理器
return new CreditCardProcessor().charge(details);
}
}
class CreditCardProcessor {
public PaymentResponse charge(PaymentDetails details) {
// 處理信用卡支付邏輯
return new PaymentResponse();
}
}
重構(gòu)后：
interface IPaymentProcessor {
PaymentResponse charge(PaymentDetails details);
}
class CreditCardProcessor implements IPaymentProcessor {
public PaymentResponse charge(PaymentDetails details) {
// 處理信用卡支付邏輯
return new PaymentResponse();
}
}
class PayPalProcessor implements IPaymentProcessor {
public PaymentResponse charge(PaymentDetails details) {
// 處理PayPal支付邏輯
return new PaymentResponse();
}
}
class PaymentGateway {
private IPaymentProcessor paymentProcessor;
public PaymentGateway(IPaymentProcessor paymentProcessor) {
this.paymentProcessor = paymentProcessor;
}
public PaymentResponse processPayment(PaymentDetails details) {
// 依賴于抽象的支付處理器接口
return paymentProcessor.charge(details);
}
}
// 使用PaymentGateway
PaymentGateway gateway = new PaymentGateway(new CreditCardProcessor());
PaymentResponse response = gateway.processPayment(new PaymentDetails());
7.1 ERP 案例
重構(gòu)前：
public class FinancialModule {
public void generateReports() {
// 直接依賴于具體的數(shù)據(jù)庫報告生成服務(wù)
DatabaseReportingService service = new DatabaseReportingService();
service.generate(...);
}
}
class DatabaseReportingService {
public void generate(/* parameters */) {
// 從數(shù)據(jù)庫生成報告的邏輯
}
}
問題分析：
-
緊耦合:
FinancialModule直接依賴于DatabaseReportingService的具體實現(xiàn)，耦合度高奶浦，導(dǎo)致系統(tǒng)靈活性差兄墅。 -
擴展性差: 當(dāng)需要添加新的報告生成方式（例如基于文件的報告）時，可能需要修改
FinancialModule的代碼澳叉，這違背了開閉原則隙咸。 -
維護(hù)困難: 如果
DatabaseReportingService的接口或?qū)崿F(xiàn)發(fā)生變化，可能會影響到FinancialModule成洗，增加了維護(hù)成本五督。 -
測試復(fù)雜性: 直接依賴具體實現(xiàn)使得單元測試
FinancialModule變得復(fù)雜，可能需要大量模擬（mocking）具體類瓶殃。 -
代碼重復(fù): 如果系統(tǒng)中其他模塊也需要生成報告充包，可能會復(fù)制
FinancialModule中的代碼，導(dǎo)致代碼重復(fù)遥椿。
重構(gòu)后：
interface ReportingService {
void generate(ReportRequest request);
}
class DatabaseReportingService implements ReportingService {
public void generate(ReportRequest request) {
// 從數(shù)據(jù)庫生成報告的邏輯
}
}
class FileBasedReportingService implements ReportingService {
public void generate(ReportRequest request) {
// 從文件生成報告的邏輯
}
}
class FinancialModule {
private ReportingService reportingService;
public FinancialModule(ReportingService reportingService) {
this.reportingService = reportingService;
}
public void generateReports(ReportRequest request) {
// 使用抽象的報告服務(wù)生成報告
reportingService.generate(request);
}
}
// 使用FinancialModule
FinancialModule financialModule = new FinancialModule(new DatabaseReportingService());
financialModule.generateReports(new ReportRequest());
解決的問題：
-
解耦合:
FinancialModule現(xiàn)在依賴于ReportingService接口基矮，而不是任何具體實現(xiàn)，降低了耦合度冠场。 -
擴展性增強: 新的報告生成方式（如
FileBasedReportingService）可以通過實現(xiàn)ReportingService接口輕松添加家浇，無需修改FinancialModule。 -
維護(hù)簡化: 由于
FinancialModule不依賴于具體實現(xiàn)碴裙，因此維護(hù)和升級報告生成服務(wù)時對FinancialModule的影響較小钢悲。 -
測試簡化: 可以輕松地為
FinancialModule編寫單元測試，只需模擬ReportingService接口舔株，而不是具體實現(xiàn)莺琳。 -
代碼復(fù)用: 其他需要報告生成功能的模塊可以重用
FinancialModule，通過注入不同的ReportingService實現(xiàn)來滿足特定需求督笆。 -
依賴注入: 通過構(gòu)造函數(shù)或設(shè)置器注入
ReportingService的實現(xiàn)芦昔，提高了FinancialModule的靈活性和可配置性。 -
單一職責(zé):
FinancialModule專注于其業(yè)務(wù)邏輯娃肿，而報告生成的具體細(xì)節(jié)由ReportingService的實現(xiàn)負(fù)責(zé)咕缎，符合單一職責(zé)原則珠十。
8. 參考開源框架：
在Apache Camel等集成框架中，通過使用自定義組件和處理器凭豪，遵循依賴倒置原則焙蹭，實現(xiàn)靈活的消息路由和處理。
9. 總結(jié)：
依賴倒置原則在支付網(wǎng)關(guān)設(shè)計中的應(yīng)用嫂伞，通過引入抽象層孔厉，有效地解耦了業(yè)務(wù)邏輯與具體支付實現(xiàn)。這不僅提高了系統(tǒng)的靈活性和可擴展性帖努，也使得新增或修改支付方式變得更加簡單撰豺。遵循依賴倒置原則有助于構(gòu)建更加健壯、易于維護(hù)的系統(tǒng)拼余，尤其是在需要支持多種支付方式的電子商務(wù)平臺中污桦。
歷史熱點文章
- 享元模式（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)案例分析
