<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>依賴注入 on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E4%BE%9D%E8%B3%B4%E6%B3%A8%E5%85%A5/</link><description>Recent content in 依賴注入 on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Mon, 13 Jul 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E4%BE%9D%E8%B3%B4%E6%B3%A8%E5%85%A5/index.xml" rel="self" type="application/rss+xml"/><item><title>Dependency Injection</title><link>https://tarrragon.github.io/blog/ddd/knowledge-cards/dependency-injection/</link><pubDate>Mon, 13 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/ddd/knowledge-cards/dependency-injection/</guid><description>&lt;p>依賴注入（dependency injection、DI）把「建構依賴」跟「使用依賴」分成兩個責任：物件宣告它需要什麼（通常以 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/port/" data-link-title="Port" data-link-desc="判斷介面該宣告在哪一層、依賴方向該朝哪時使用。port 是 domain 對外宣告的介面——需求用領域語言說完、技術細節留在實作端。">port&lt;/a> 這樣的介面表達）、實例由外部在組裝時提供——最基本的形式是建構子參數。物件自己建構依賴時、依賴的選擇被寫死在使用處；改由外部注入後、同一段程式碼在 production 拿到真實 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/adapter/" data-link-title="Adapter" data-link-desc="把領域需求翻譯成具體技術操作的實作該放哪、跟領域的邊界在哪時使用。adapter 是 port 的具體實作——技術細節被擋在六角形之外的位置。">adapter&lt;/a>、在測試拿到替身。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>DI 容器是框架提供的註冊與解析機制、把「哪個介面對應哪個實作」收成一份註冊表：啟動時註冊、使用時解析——每一條可解析的註冊項就是一個注入項、部分生態稱它 provider。注入的集中點是 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/composition-root/" data-link-title="Composition Root" data-link-desc="依賴組裝、路由註冊該集中在哪、組裝斷裂去哪檢查時使用。composition root 是應用程式唯一的組裝起點——DI、路由、事件接線的集中處。">composition root&lt;/a>：全部具體型別在這裡被決定。測試框架的 override 機制（用替身蓋過註冊項）是 DI 給測試的 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/test-seam/" data-link-title="Test Seam" data-link-desc="測試想把真實依賴換成替身、該從哪裡換時使用。seam 是不修改程式本體就能替換其中一段行為的位置——介面加注入點是物件導向最常見的形式。">seam&lt;/a>。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>建構子收介面、具體實作的選擇集中在組裝處，是注入責任歸位的訊號。類別內部直接建構自己的依賴（new 具體型別、呼叫全域單例）時、該依賴在測試裡換不掉、技術選擇散落各層。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>注入讓「誰提供真實作」成為一個獨立責任。這個責任有沒有被履行——每個注入項在無 override 環境解析得了——在行為測試裡沒有證言（綠燈證明不了它）、要由 &lt;a href="https://tarrragon.github.io/blog/ddd/knowledge-cards/wiring-test/" data-link-title="Wiring Test" data-link-desc="行為測試全綠、還想知道組裝有沒有完成時使用。接線測試在組裝路徑零 override 的環境解析每個注入項、走真實路由表，只驗「port 插上了 adapter」。">接線測試&lt;/a> 驗證；教學層展開見 &lt;a href="https://tarrragon.github.io/blog/ddd/composition-root-reachability/" data-link-title="組裝層的可達性" data-link-desc="行為測試全綠、功能在實機上沒有入口的失效形態出現時使用。mock 換掉的正是組裝，組裝完成與否在行為測試裡沒有證言；把可達性當成組裝層的不變式，在測試、發版與設計文件各給一個強制點。">組裝層的可達性&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>依賴注入（dependency injection、DI）把「建構依賴」跟「使用依賴」分成兩個責任：物件宣告它需要什麼（通常以 <a href="/blog/ddd/knowledge-cards/port/" data-link-title="Port" data-link-desc="判斷介面該宣告在哪一層、依賴方向該朝哪時使用。port 是 domain 對外宣告的介面——需求用領域語言說完、技術細節留在實作端。">port</a> 這樣的介面表達）、實例由外部在組裝時提供——最基本的形式是建構子參數。物件自己建構依賴時、依賴的選擇被寫死在使用處；改由外部注入後、同一段程式碼在 production 拿到真實 <a href="/blog/ddd/knowledge-cards/adapter/" data-link-title="Adapter" data-link-desc="把領域需求翻譯成具體技術操作的實作該放哪、跟領域的邊界在哪時使用。adapter 是 port 的具體實作——技術細節被擋在六角形之外的位置。">adapter</a>、在測試拿到替身。</p>
<h2 id="概念位置">概念位置</h2>
<p>DI 容器是框架提供的註冊與解析機制、把「哪個介面對應哪個實作」收成一份註冊表：啟動時註冊、使用時解析——每一條可解析的註冊項就是一個注入項、部分生態稱它 provider。注入的集中點是 <a href="/blog/ddd/knowledge-cards/composition-root/" data-link-title="Composition Root" data-link-desc="依賴組裝、路由註冊該集中在哪、組裝斷裂去哪檢查時使用。composition root 是應用程式唯一的組裝起點——DI、路由、事件接線的集中處。">composition root</a>：全部具體型別在這裡被決定。測試框架的 override 機制（用替身蓋過註冊項）是 DI 給測試的 <a href="/blog/ddd/knowledge-cards/test-seam/" data-link-title="Test Seam" data-link-desc="測試想把真實依賴換成替身、該從哪裡換時使用。seam 是不修改程式本體就能替換其中一段行為的位置——介面加注入點是物件導向最常見的形式。">seam</a>。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>建構子收介面、具體實作的選擇集中在組裝處，是注入責任歸位的訊號。類別內部直接建構自己的依賴（new 具體型別、呼叫全域單例）時、該依賴在測試裡換不掉、技術選擇散落各層。</p>
<h2 id="設計責任">設計責任</h2>
<p>注入讓「誰提供真實作」成為一個獨立責任。這個責任有沒有被履行——每個注入項在無 override 環境解析得了——在行為測試裡沒有證言（綠燈證明不了它）、要由 <a href="/blog/ddd/knowledge-cards/wiring-test/" data-link-title="Wiring Test" data-link-desc="行為測試全綠、還想知道組裝有沒有完成時使用。接線測試在組裝路徑零 override 的環境解析每個注入項、走真實路由表，只驗「port 插上了 adapter」。">接線測試</a> 驗證；教學層展開見 <a href="/blog/ddd/composition-root-reachability/" data-link-title="組裝層的可達性" data-link-desc="行為測試全綠、功能在實機上沒有入口的失效形態出現時使用。mock 換掉的正是組裝，組裝完成與否在行為測試裡沒有證言；把可達性當成組裝層的不變式，在測試、發版與設計文件各給一個強制點。">組裝層的可達性</a>。</p>
]]></content:encoded></item></channel></rss>