計哲學)
在C#面向?qū)ο蟮膶W習路徑中接口Interface和抽象類Abstract Class是兩個繞不開的核心概念。很多開發(fā)者雖然能熟練寫出語法卻常?；煜叩脑O(shè)計意圖。今天我想從一個更生活化的視角重新解讀它們接口是“適配器”抽象類是“毛坯房”。這個比喻或許能幫你跳出語法的桎梏真正理解它們的本質(zhì)差異。一、接口跨系統(tǒng)的“適配器”想象一下你有一個Type-C接口的手機但手邊只有一個USB-A的充電器。這時候你需要一個轉(zhuǎn)接頭——它不改變充電器的核心功能供電只是讓“充電器”和“手機”能順利對接。這個轉(zhuǎn)接頭就是接口的本質(zhì)適配器。接口不關(guān)心“如何實現(xiàn)功能”只關(guān)心“能提供哪些功能”。它的核心作用是定義一組行為規(guī)范讓不同的類無論血緣關(guān)系如何都能通過實現(xiàn)這個接口被統(tǒng)一的調(diào)用層識別和使用。為什么叫“實現(xiàn)”因為接口的方法沒有具體實現(xiàn)就像轉(zhuǎn)接頭只有插孔定義沒有內(nèi)部電路。實現(xiàn)接口的類必須“填充”這些方法的細節(jié)就像給轉(zhuǎn)接頭焊接內(nèi)部線路讓它真正工作。代碼示例用接口統(tǒng)一“支付”行為假設(shè)我們在開發(fā)一個電商系統(tǒng)需要支持支付寶、微信支付、銀行卡支付等多種方式。調(diào)用層的邏輯應該是“不管什么支付方式只要能完成‘支付’操作就行”。這時候接口就是最佳選擇。// 定義“支付”接口適配器publicinterfaceIPayment{// 支付方法參數(shù)金額返回是否成功boolPay(decimalamount);}// 支付寶類實現(xiàn)IPayment接口publicclassAlipay:IPayment{publicboolPay(decimalamount){Console.WriteLine($支付寶支付{amount}元);// 實際調(diào)用支付寶SDK的邏輯...returntrue;}}// 微信支付類實現(xiàn)IPayment接口publicclassWeChatPay:IPayment{publicboolPay(decimalamount){Console.WriteLine($微信支付{amount}元);// 實際調(diào)用微信支付API的邏輯...returntrue;}}// 調(diào)用層完全依賴接口不關(guān)心具體實現(xiàn)publicclassPaymentService{publicvoidProcessPayment(IPaymentpayment,decimalamount){payment.Pay(amount);// 所有實現(xiàn)了IPayment的類都能被調(diào)用}}// 使用示例varservicenewPaymentService();service.ProcessPayment(newAlipay(),100);// 支付寶支付100元service.ProcessPayment(newWeChatPay(),200);// 微信支付200元這里IPayment就是那個“適配器”。支付寶和微信支付是完全不同的類甚至沒有繼承關(guān)系但通過實現(xiàn)IPayment它們都能被PaymentService無縫調(diào)用。接口的核心是“功能契約”解決的是“能不能做”的問題。二、抽象類預留架構(gòu)的“毛坯房”如果說接口是轉(zhuǎn)接頭那抽象類就是“毛坯房”。開發(fā)商建好毛坯房后會預留承重墻、水電管道等固定架構(gòu)——這些是房子成立的基礎(chǔ)但墻面刷漆、地板鋪設(shè)等裝修細節(jié)則交給業(yè)主自己決定。抽象類正是如此它定義了子類的核心架構(gòu)公共字段、方法實現(xiàn)、抽象方法子類只需“裝修”實現(xiàn)抽象方法即可但必須繼承整個架構(gòu)。為什么叫“繼承”因為抽象類是一個“半成品”子類必須通過繼承獲得它的全部成員包括已實現(xiàn)的方法和未實現(xiàn)的抽象方法。就像你買了毛坯房必須接受它的戶型和水電布局不能只挑喜歡的墻面而丟棄承重墻。為什么叫“毛坯房”抽象類可以包含具體實現(xiàn)的方法比如毛坯房的水電管道也可以包含抽象方法比如預留的插座位置而子類裝修后的房子必須實現(xiàn)這些抽象方法安裝插座但可以自由擴展貼壁紙、裝吊燈。代碼示例用抽象類統(tǒng)一“動物”的生存邏輯假設(shè)我們需要建模“動物”所有動物都有“呼吸”“移動”的行為但“移動”的具體方式跑、飛、游因種類而異。這時候抽象類就能很好地封裝公共邏輯同時保留擴展空間。// 抽象類動物毛坯房publicabstractclassAnimal{// 已實現(xiàn)的方法所有動物都需要呼吸毛坯房的水電管道publicvoidBreathe(){Console.WriteLine(動物正在呼吸...);}// 抽象方法移動方式由子類實現(xiàn)預留的插座位置publicabstractvoidMove();// 虛方法可被重寫可選的裝修項比如加裝智能家居publicvirtualvoidEat(){Console.WriteLine(動物正在進食...);}}// 狗類繼承Animal裝修成“狗窩”publicclassDog:Animal{// 必須實現(xiàn)抽象方法Move安裝插座publicoverridevoidMove(){Console.WriteLine(狗用四條腿奔跑);}// 可選重寫虛方法Eat加裝智能喂食器publicoverridevoidEat(){Console.WriteLine(狗啃骨頭);}}// 鳥類繼承Animal裝修成“鳥巢”publicclassBird:Animal{publicoverridevoidMove(){Console.WriteLine(鳥扇動翅膀飛翔);}// 不重寫Eat使用父類的默認實現(xiàn)使用基礎(chǔ)裝修}// 調(diào)用層依賴抽象類AnimalpublicclassZoo{// ? 依賴的是抽象Animal而不是具體Dog/BirdpublicvoidLetAnimalMove(Animalanimal){animal.Move();}}// 使用示例ZoozoonewZoo();AnimaldognewDog();// 多態(tài)父類引用指向子類對象AnimalbirdnewBird();zoo.LetAnimalMove(dog);// 輸出狗用四條腿奔跑zoo.LetAnimalMove(bird);// 輸出鳥扇動翅膀飛翔這里Animal是毛坯房它實現(xiàn)了Breathe水電管道定義了抽象的Move預留插座還提供了可重寫的Eat可選裝修。Dog和Bird繼承了Animal的所有架構(gòu)只需要實現(xiàn)Move裝修插座并可以選擇是否重寫Eat升級裝修。抽象類的核心是“架構(gòu)復用”解決的是“是什么”的問題。三、深入解析把 new 封裝進函數(shù) —— 輕量級解耦方案很多同學在學習了“上層依賴接口”之后會有一個很大的疑惑“道理我都懂但如果我有一千個地方調(diào)用了這個接口現(xiàn)在要把底層實現(xiàn)從 SqlServerDao 換成 MySqlDao難道要改一千個地方的 new 嗎”其實在引入重量級的 IoC 容器之前還有一種非常經(jīng)典且實用的方法來實現(xiàn)解耦工廠模式Factory Pattern。它的核心思想是把 new 這個動作封裝起來隱藏到一個獨立的函數(shù)中。1. 傳統(tǒng)寫法的痛點如果按照最原始的順掛寫法業(yè)務(wù)層直接 new 具體的實現(xiàn)類一旦底層變動上層必死無疑。// 糟糕的順掛業(yè)務(wù)層直接依賴具體實現(xiàn)publicclassOrderService{publicvoidCreateOrder(){// 緊緊耦合換庫如換頭varreponewSqlServerOrderDao();repo.Save();}}2. 工廠模式隱藏 new 的魔法我們可以創(chuàng)建一個專門的工廠類用來負責對象的創(chuàng)建工作。調(diào)用端不再關(guān)心對象是怎么來的只管向工廠索要。// 1. 依然是接口定義契約publicinterfaceIOrderRepository{voidSave();}// 2. 底層實現(xiàn)依然是孫子publicclassSqlServerOrderDao:IOrderRepository{publicvoidSave()Console.WriteLine(保存到 SQL Server);}publicclassMySqlOrderDao:IOrderRepository{publicvoidSave()Console.WriteLine(保存到 MySQL);}// 3. 【新增】工廠類專門負責干“new”這個臟活累活publicstaticclassOrderRepositoryFactory{// 這里就是唯一的“倒掛”點。整個項目只有這里知道用的是 SQL Server。publicstaticIOrderRepositoryCreate(){returnnewSqlServerOrderDao();// 哪天要換 MySQL只需要改這一行調(diào)用端毫無感知。}}3. 調(diào)用端的絲滑體驗現(xiàn)在的業(yè)務(wù)代碼看起來非常清爽完全沒有 new 關(guān)鍵字也沒有依賴具體的實現(xiàn)類。// 調(diào)用端一千個地方都是這么寫毫無壓力publicclassOrderService{publicvoidCreateOrder(){// 我只管向工廠要一個能存訂單的東西我不關(guān)心它是誰生的IOrderRepositoryrepoOrderRepositoryFactory.Create();repo.Save();}}4. 工廠模式 vs IoC 容器既然有了工廠模式為什么還要學復雜的 IoC 容器呢維度工廠模式封裝newIoC 容器全自動依賴注入控制權(quán)人肉管理。你需要手動去工廠類里修改代碼才能切換實現(xiàn)。容器管理。通過配置文件或反射連工廠類都不用動。生命周期較難管理。比如“這個對象是全局唯一單例”還是“每次都要新建瞬時”工廠代碼寫起來很啰嗦。自帶生命周期管理。一行代碼搞定單例、作用域等。參數(shù)傳遞困難。如果構(gòu)造函數(shù)需要傳很多配置參數(shù)如appKey工廠里還得想辦法拿到這些參數(shù)。輕松。容器會自動把配置文件里的參數(shù)注入進去。適用場景中小型項目、邏輯簡單的模塊。改動少夠用就好。大型復雜系統(tǒng)。模塊多、依賴關(guān)系錯綜復雜時必須用。四、容器模式依賴注入DI與IoC容器在大型項目中對象之間的依賴關(guān)系往往像一張錯綜復雜的網(wǎng)。如果每個對象都自己去new它的依賴就像前面說的“順掛”那么代碼的維護將是一場噩夢。為了解決這個問題IoCInversion of Control控制反轉(zhuǎn)容器在C#中最著名的實現(xiàn)就是ASP.NET Core自帶的依賴注入容器登場了。它是依賴倒置原則的終極武器。核心思想把“出生權(quán)”交給容器在工廠模式中我們雖然把new藏起來了但調(diào)用端還是需要主動去“要”對象Factory.Create()。而在容器模式中你什么都不用管。你只需要告訴容器“我需要一個IOrderRepository”容器就會自動把它管理下的SqlServerOrderDao或者你配置好的任何實現(xiàn)送過來。這個過程叫做依賴注入Dependency Injection, DI。最關(guān)鍵的區(qū)別在于? 順掛/工廠對象自己決定依賴從哪里來自己new或找工廠要。? 容器模式對象不再主動索取而是由外部容器把依賴“注射”給它。這就是“控制反轉(zhuǎn)”——創(chuàng)建對象的控制權(quán)從業(yè)務(wù)代碼反轉(zhuǎn)到了容器手中。代碼示例告別 new擁抱注入我們還是用剛才的訂單保存場景看看容器模式是如何工作的// 1. 依然是接口和底層實現(xiàn)不變publicinterfaceIOrderRepository{voidSave();}publicclassSqlServerOrderDao:IOrderRepository{publicvoidSave()Console.WriteLine(保存到 SQL Server);}// 2. 業(yè)務(wù)層徹底甩掉“怎么創(chuàng)建”的包袱publicclassOrderService{privatereadonlyIOrderRepository_repo;// 構(gòu)造函數(shù)我不管_repo怎么來的反正你容器得給我一個// 這就是“依賴注入”——容器把依賴注入到構(gòu)造函數(shù)里publicOrderService(IOrderRepositoryrepo){_reporepo;}publicvoidCreateOrder(){_repo.Save();}}// 3. 【核心】程序入口配置容器唯一需要寫底層類名的地方publicclassProgram{publicstaticvoidMain(){// 創(chuàng)建一個容器建造器varservicesnewServiceCollection();// 注冊依賴告訴容器以后要IOrderRepository就給SqlServerOrderDao// 這里還可以指定生命周期如 Scoped, Singleton, Transientservices.AddScopedIOrderRepository,SqlServerOrderDao();// 把上層服務(wù)也交給容器管理services.AddScopedOrderService();// 構(gòu)建容器varserviceProviderservices.BuildServiceProvider();// 4. 調(diào)用端完全不需要 new直接從容器要成品// 容器會自動解析 OrderService 的依賴鏈并把一切都準備好varorderServiceserviceProvider.GetRequiredServiceOrderService();orderService.CreateOrder();}}為什么說這是“終極倒掛”假設(shè)現(xiàn)在有一千個地方調(diào)用了OrderService或者是OrderService依賴了十幾個其他的類如日志、緩存、消息隊列等。無感切換如果要換成MySQL你只需要修改Program.cs里的這一行// 原來services.AddScopedIOrderRepository, SqlServerOrderDao();services.AddScopedIOrderRepository,MySqlOrderDao();那一千個調(diào)用點和OrderService的業(yè)務(wù)邏輯一個字都不用改。生命周期管理如果SqlServerOrderDao需要數(shù)據(jù)庫連接池或者需要是單例模式你只需要在注冊時聲明AddSingleton容器會自動幫你管理對象的生死輪回業(yè)務(wù)代碼完全不關(guān)心這些“臟活”。配置化在ASP.NET Core中這一步甚至可以做到完全脫離代碼放到appsettings.json配置文件中。換數(shù)據(jù)庫連代碼編譯都不需要改個配置重啟即可。五、關(guān)鍵差異對比適配器 vs 毛坯房維度接口適配器抽象類毛坯房核心目的定義功能契約實現(xiàn)跨類型協(xié)作封裝公共架構(gòu)實現(xiàn)代碼復用關(guān)鍵字interface:實現(xiàn)abstract class:繼承方法實現(xiàn)無實現(xiàn)C#8.0后支持默認實現(xiàn)但仍以契約為核心可包含已實現(xiàn)方法和抽象方法繼承限制類可實現(xiàn)多個接口類只能繼承一個抽象類單繼承設(shè)計側(cè)重「能不能做」功能/解耦「是什么」類型/復用六、總結(jié)什么時候用哪個? 用接口當你需要讓不同類甚至無關(guān)類共享同一組行為且不關(guān)心它們的實現(xiàn)細節(jié)時。比如支付、日志、緩存等功能模塊。接口是落實依賴倒置原則的首選武器。? 用抽象類當你需要定義一組緊密相關(guān)的類的公共架構(gòu)且希望復用代碼時。比如動物、形狀、業(yè)務(wù)實體等具有明顯層級關(guān)系的場景。? 用工廠模式當你不想引入龐大的 IoC 容器但又想把 new 操作隔離出去保護上層業(yè)務(wù)代碼不被底層實現(xiàn)變動所影響時。它是輕量級解耦的利器。? 用IoC容器當你面對的是企業(yè)級大型應用對象之間依賴關(guān)系復雜且需要精細控制對象生命周期如單例、請求作用域時。它是現(xiàn)代.NET開發(fā)的標配?；氐阶畛醯谋扔? 接口是轉(zhuǎn)接頭讓不同設(shè)備能對話接口定義了對話的標準? 抽象類是毛坯房讓同類建筑共享基礎(chǔ)架構(gòu)? 工廠是手工生產(chǎn)線把具體的制造過程隱藏起來? IoC容器是全自動智能工廠不僅負責生產(chǎn)還負責物流配送和庫存管理。理解這四者的分工與協(xié)作你就能在設(shè)計時更從容地選擇工具寫出更符合面向?qū)ο笏枷?、更易維護的代碼。希望這篇博客能幫你跳出“語法記憶”真正觸摸到接口和抽象類的設(shè)計靈魂。如果有疑問歡迎在評論區(qū)討論 再談C#的抽象類和接口：從“適配器”到“毛坯房”的設(shè)計哲學
在C#面向?qū)ο蟮膶W習路徑中接口Interface和抽象類Abstract Class是兩個繞不開的核心概念。很多開發(fā)者雖然能熟練寫出語法卻常?；煜叩脑O(shè)計意圖。今天我想從一個更生活化的視角重新解讀它們接口是“適配器”抽象類是“毛坯房”。這個比喻或許能幫你跳出語法的桎梏真正理解它們的本質(zhì)差異。一、接口跨系統(tǒng)的“適配器”想象一下你有一個Type-C接口的手機但手邊只有一個USB-A的充電器。這時候你需要一個轉(zhuǎn)接頭——它不改變充電器的核心功能供電只是讓“充電器”和“手機”能順利對接。這個轉(zhuǎn)接頭就是接口的本質(zhì)適配器。接口不關(guān)心“如何實現(xiàn)功能”只關(guān)心“能提供哪些功能”。它的核心作用是定義一組行為規(guī)范讓不同的類無論血緣關(guān)系如何都能通過實現(xiàn)這個接口被統(tǒng)一的調(diào)用層識別和使用。為什么叫“實現(xiàn)”因為接口的方法沒有具體實現(xiàn)就像轉(zhuǎn)接頭只有插孔定義沒有內(nèi)部電路。實現(xiàn)接口的類必須“填充”這些方法的細節(jié)就像給轉(zhuǎn)接頭焊接內(nèi)部線路讓它真正工作。代碼示例用接口統(tǒng)一“支付”行為假設(shè)我們在開發(fā)一個電商系統(tǒng)需要支持支付寶、微信支付、銀行卡支付等多種方式。調(diào)用層的邏輯應該是“不管什么支付方式只要能完成‘支付’操作就行”。這時候接口就是最佳選擇。// 定義“支付”接口適配器publicinterfaceIPayment{// 支付方法參數(shù)金額返回是否成功boolPay(decimalamount);}// 支付寶類實現(xiàn)IPayment接口publicclassAlipay:IPayment{publicboolPay(decimalamount){Console.WriteLine($支付寶支付{amount}元);// 實際調(diào)用支付寶SDK的邏輯...returntrue;}}// 微信支付類實現(xiàn)IPayment接口publicclassWeChatPay:IPayment{publicboolPay(decimalamount){Console.WriteLine($微信支付{amount}元);// 實際調(diào)用微信支付API的邏輯...returntrue;}}// 調(diào)用層完全依賴接口不關(guān)心具體實現(xiàn)publicclassPaymentService{publicvoidProcessPayment(IPaymentpayment,decimalamount){payment.Pay(amount);// 所有實現(xiàn)了IPayment的類都能被調(diào)用}}// 使用示例varservicenewPaymentService();service.ProcessPayment(newAlipay(),100);// 支付寶支付100元service.ProcessPayment(newWeChatPay(),200);// 微信支付200元這里IPayment就是那個“適配器”。支付寶和微信支付是完全不同的類甚至沒有繼承關(guān)系但通過實現(xiàn)IPayment它們都能被PaymentService無縫調(diào)用。接口的核心是“功能契約”解決的是“能不能做”的問題。二、抽象類預留架構(gòu)的“毛坯房”如果說接口是轉(zhuǎn)接頭那抽象類就是“毛坯房”。開發(fā)商建好毛坯房后會預留承重墻、水電管道等固定架構(gòu)——這些是房子成立的基礎(chǔ)但墻面刷漆、地板鋪設(shè)等裝修細節(jié)則交給業(yè)主自己決定。抽象類正是如此它定義了子類的核心架構(gòu)公共字段、方法實現(xiàn)、抽象方法子類只需“裝修”實現(xiàn)抽象方法即可但必須繼承整個架構(gòu)。為什么叫“繼承”因為抽象類是一個“半成品”子類必須通過繼承獲得它的全部成員包括已實現(xiàn)的方法和未實現(xiàn)的抽象方法。就像你買了毛坯房必須接受它的戶型和水電布局不能只挑喜歡的墻面而丟棄承重墻。為什么叫“毛坯房”抽象類可以包含具體實現(xiàn)的方法比如毛坯房的水電管道也可以包含抽象方法比如預留的插座位置而子類裝修后的房子必須實現(xiàn)這些抽象方法安裝插座但可以自由擴展貼壁紙、裝吊燈。代碼示例用抽象類統(tǒng)一“動物”的生存邏輯假設(shè)我們需要建模“動物”所有動物都有“呼吸”“移動”的行為但“移動”的具體方式跑、飛、游因種類而異。這時候抽象類就能很好地封裝公共邏輯同時保留擴展空間。// 抽象類動物毛坯房publicabstractclassAnimal{// 已實現(xiàn)的方法所有動物都需要呼吸毛坯房的水電管道publicvoidBreathe(){Console.WriteLine(動物正在呼吸...);}// 抽象方法移動方式由子類實現(xiàn)預留的插座位置publicabstractvoidMove();// 虛方法可被重寫可選的裝修項比如加裝智能家居publicvirtualvoidEat(){Console.WriteLine(動物正在進食...);}}// 狗類繼承Animal裝修成“狗窩”publicclassDog:Animal{// 必須實現(xiàn)抽象方法Move安裝插座publicoverridevoidMove(){Console.WriteLine(狗用四條腿奔跑);}// 可選重寫虛方法Eat加裝智能喂食器publicoverridevoidEat(){Console.WriteLine(狗啃骨頭);}}// 鳥類繼承Animal裝修成“鳥巢”publicclassBird:Animal{publicoverridevoidMove(){Console.WriteLine(鳥扇動翅膀飛翔);}// 不重寫Eat使用父類的默認實現(xiàn)使用基礎(chǔ)裝修}// 調(diào)用層依賴抽象類AnimalpublicclassZoo{// ? 依賴的是抽象Animal而不是具體Dog/BirdpublicvoidLetAnimalMove(Animalanimal){animal.Move();}}// 使用示例ZoozoonewZoo();AnimaldognewDog();// 多態(tài)父類引用指向子類對象AnimalbirdnewBird();zoo.LetAnimalMove(dog);// 輸出狗用四條腿奔跑zoo.LetAnimalMove(bird);// 輸出鳥扇動翅膀飛翔這里Animal是毛坯房它實現(xiàn)了Breathe水電管道定義了抽象的Move預留插座還提供了可重寫的Eat可選裝修。Dog和Bird繼承了Animal的所有架構(gòu)只需要實現(xiàn)Move裝修插座并可以選擇是否重寫Eat升級裝修。抽象類的核心是“架構(gòu)復用”解決的是“是什么”的問題。三、深入解析把 new 封裝進函數(shù) —— 輕量級解耦方案很多同學在學習了“上層依賴接口”之后會有一個很大的疑惑“道理我都懂但如果我有一千個地方調(diào)用了這個接口現(xiàn)在要把底層實現(xiàn)從 SqlServerDao 換成 MySqlDao難道要改一千個地方的 new 嗎”其實在引入重量級的 IoC 容器之前還有一種非常經(jīng)典且實用的方法來實現(xiàn)解耦工廠模式Factory Pattern。它的核心思想是把 new 這個動作封裝起來隱藏到一個獨立的函數(shù)中。1. 傳統(tǒng)寫法的痛點如果按照最原始的順掛寫法業(yè)務(wù)層直接 new 具體的實現(xiàn)類一旦底層變動上層必死無疑。// 糟糕的順掛業(yè)務(wù)層直接依賴具體實現(xiàn)publicclassOrderService{publicvoidCreateOrder(){// 緊緊耦合換庫如換頭varreponewSqlServerOrderDao();repo.Save();}}2. 工廠模式隱藏 new 的魔法我們可以創(chuàng)建一個專門的工廠類用來負責對象的創(chuàng)建工作。調(diào)用端不再關(guān)心對象是怎么來的只管向工廠索要。// 1. 依然是接口定義契約publicinterfaceIOrderRepository{voidSave();}// 2. 底層實現(xiàn)依然是孫子publicclassSqlServerOrderDao:IOrderRepository{publicvoidSave()Console.WriteLine(保存到 SQL Server);}publicclassMySqlOrderDao:IOrderRepository{publicvoidSave()Console.WriteLine(保存到 MySQL);}// 3. 【新增】工廠類專門負責干“new”這個臟活累活publicstaticclassOrderRepositoryFactory{// 這里就是唯一的“倒掛”點。整個項目只有這里知道用的是 SQL Server。publicstaticIOrderRepositoryCreate(){returnnewSqlServerOrderDao();// 哪天要換 MySQL只需要改這一行調(diào)用端毫無感知。}}3. 調(diào)用端的絲滑體驗現(xiàn)在的業(yè)務(wù)代碼看起來非常清爽完全沒有 new 關(guān)鍵字也沒有依賴具體的實現(xiàn)類。// 調(diào)用端一千個地方都是這么寫毫無壓力publicclassOrderService{publicvoidCreateOrder(){// 我只管向工廠要一個能存訂單的東西我不關(guān)心它是誰生的IOrderRepositoryrepoOrderRepositoryFactory.Create();repo.Save();}}4. 工廠模式 vs IoC 容器既然有了工廠模式為什么還要學復雜的 IoC 容器呢維度工廠模式封裝newIoC 容器全自動依賴注入控制權(quán)人肉管理。你需要手動去工廠類里修改代碼才能切換實現(xiàn)。容器管理。通過配置文件或反射連工廠類都不用動。生命周期較難管理。比如“這個對象是全局唯一單例”還是“每次都要新建瞬時”工廠代碼寫起來很啰嗦。自帶生命周期管理。一行代碼搞定單例、作用域等。參數(shù)傳遞困難。如果構(gòu)造函數(shù)需要傳很多配置參數(shù)如appKey工廠里還得想辦法拿到這些參數(shù)。輕松。容器會自動把配置文件里的參數(shù)注入進去。適用場景中小型項目、邏輯簡單的模塊。改動少夠用就好。大型復雜系統(tǒng)。模塊多、依賴關(guān)系錯綜復雜時必須用。四、容器模式依賴注入DI與IoC容器在大型項目中對象之間的依賴關(guān)系往往像一張錯綜復雜的網(wǎng)。如果每個對象都自己去new它的依賴就像前面說的“順掛”那么代碼的維護將是一場噩夢。為了解決這個問題IoCInversion of Control控制反轉(zhuǎn)容器在C#中最著名的實現(xiàn)就是ASP.NET Core自帶的依賴注入容器登場了。它是依賴倒置原則的終極武器。核心思想把“出生權(quán)”交給容器在工廠模式中我們雖然把new藏起來了但調(diào)用端還是需要主動去“要”對象Factory.Create()。而在容器模式中你什么都不用管。你只需要告訴容器“我需要一個IOrderRepository”容器就會自動把它管理下的SqlServerOrderDao或者你配置好的任何實現(xiàn)送過來。這個過程叫做依賴注入Dependency Injection, DI。最關(guān)鍵的區(qū)別在于? 順掛/工廠對象自己決定依賴從哪里來自己new或找工廠要。? 容器模式對象不再主動索取而是由外部容器把依賴“注射”給它。這就是“控制反轉(zhuǎn)”——創(chuàng)建對象的控制權(quán)從業(yè)務(wù)代碼反轉(zhuǎn)到了容器手中。代碼示例告別 new擁抱注入我們還是用剛才的訂單保存場景看看容器模式是如何工作的// 1. 依然是接口和底層實現(xiàn)不變publicinterfaceIOrderRepository{voidSave();}publicclassSqlServerOrderDao:IOrderRepository{publicvoidSave()Console.WriteLine(保存到 SQL Server);}// 2. 業(yè)務(wù)層徹底甩掉“怎么創(chuàng)建”的包袱publicclassOrderService{privatereadonlyIOrderRepository_repo;// 構(gòu)造函數(shù)我不管_repo怎么來的反正你容器得給我一個// 這就是“依賴注入”——容器把依賴注入到構(gòu)造函數(shù)里publicOrderService(IOrderRepositoryrepo){_reporepo;}publicvoidCreateOrder(){_repo.Save();}}// 3. 【核心】程序入口配置容器唯一需要寫底層類名的地方publicclassProgram{publicstaticvoidMain(){// 創(chuàng)建一個容器建造器varservicesnewServiceCollection();// 注冊依賴告訴容器以后要IOrderRepository就給SqlServerOrderDao// 這里還可以指定生命周期如 Scoped, Singleton, Transientservices.AddScopedIOrderRepository,SqlServerOrderDao();// 把上層服務(wù)也交給容器管理services.AddScopedOrderService();// 構(gòu)建容器varserviceProviderservices.BuildServiceProvider();// 4. 調(diào)用端完全不需要 new直接從容器要成品// 容器會自動解析 OrderService 的依賴鏈并把一切都準備好varorderServiceserviceProvider.GetRequiredServiceOrderService();orderService.CreateOrder();}}為什么說這是“終極倒掛”假設(shè)現(xiàn)在有一千個地方調(diào)用了OrderService或者是OrderService依賴了十幾個其他的類如日志、緩存、消息隊列等。無感切換如果要換成MySQL你只需要修改Program.cs里的這一行// 原來services.AddScopedIOrderRepository, SqlServerOrderDao();services.AddScopedIOrderRepository,MySqlOrderDao();那一千個調(diào)用點和OrderService的業(yè)務(wù)邏輯一個字都不用改。生命周期管理如果SqlServerOrderDao需要數(shù)據(jù)庫連接池或者需要是單例模式你只需要在注冊時聲明AddSingleton容器會自動幫你管理對象的生死輪回業(yè)務(wù)代碼完全不關(guān)心這些“臟活”。配置化在ASP.NET Core中這一步甚至可以做到完全脫離代碼放到appsettings.json配置文件中。換數(shù)據(jù)庫連代碼編譯都不需要改個配置重啟即可。五、關(guān)鍵差異對比適配器 vs 毛坯房維度接口適配器抽象類毛坯房核心目的定義功能契約實現(xiàn)跨類型協(xié)作封裝公共架構(gòu)實現(xiàn)代碼復用關(guān)鍵字interface:實現(xiàn)abstract class:繼承方法實現(xiàn)無實現(xiàn)C#8.0后支持默認實現(xiàn)但仍以契約為核心可包含已實現(xiàn)方法和抽象方法繼承限制類可實現(xiàn)多個接口類只能繼承一個抽象類單繼承設(shè)計側(cè)重「能不能做」功能/解耦「是什么」類型/復用六、總結(jié)什么時候用哪個? 用接口當你需要讓不同類甚至無關(guān)類共享同一組行為且不關(guān)心它們的實現(xiàn)細節(jié)時。比如支付、日志、緩存等功能模塊。接口是落實依賴倒置原則的首選武器。? 用抽象類當你需要定義一組緊密相關(guān)的類的公共架構(gòu)且希望復用代碼時。比如動物、形狀、業(yè)務(wù)實體等具有明顯層級關(guān)系的場景。? 用工廠模式當你不想引入龐大的 IoC 容器但又想把 new 操作隔離出去保護上層業(yè)務(wù)代碼不被底層實現(xiàn)變動所影響時。它是輕量級解耦的利器。? 用IoC容器當你面對的是企業(yè)級大型應用對象之間依賴關(guān)系復雜且需要精細控制對象生命周期如單例、請求作用域時。它是現(xiàn)代.NET開發(fā)的標配?；氐阶畛醯谋扔? 接口是轉(zhuǎn)接頭讓不同設(shè)備能對話接口定義了對話的標準? 抽象類是毛坯房讓同類建筑共享基礎(chǔ)架構(gòu)? 工廠是手工生產(chǎn)線把具體的制造過程隱藏起來? IoC容器是全自動智能工廠不僅負責生產(chǎn)還負責物流配送和庫存管理。理解這四者的分工與協(xié)作你就能在設(shè)計時更從容地選擇工具寫出更符合面向?qū)ο笏枷?、更易維護的代碼。希望這篇博客能幫你跳出“語法記憶”真正觸摸到接口和抽象類的設(shè)計靈魂。如果有疑問歡迎在評論區(qū)討論