物件導向系列 - 3: 控制反轉與依賴注入
在實際專案中，大家是否曾注意到許多類別的建構子會呼叫其他類別作為參數，但在實際使用該類別時卻沒有傳入這些參數呢？在前兩章中，我們已經介紹了 SOLID 原則中的依賴反轉原則。這次，我們將進一步探討控制反轉與依賴注入的概念。
控制反轉（Ioc — Inversion of Control）
控制反轉是一種設計原則，將物件的控制權轉移給第三方容器（IoC 容器）。
在依賴反轉原則中，我們已經讓物件共同依賴於抽象而非具體實例。然而，如果流程運作中只是單純依序處理物件，那麼當流程改變時，實例也需要相應地調整，這樣並沒有完全解決高耦合的問題。在這種情況下，就需要利用控制反轉。舉例來說：
假設你有一個三角形與一個長方形物件，你在流程中依序計算它們的周長。當需要加入五邊形時，你除了創建五邊形物件，還需要將其加入計算流程，才能得到最終的答案。
使用控制反轉時，你可以額外創建一個 IoC 容器，在容器中執行計算周長的函數和其他功能。這樣當我們需要五邊形時，只需創建五邊形物件，並將其放入 IoC 容器中，就能獲得答案。
總結一下控制反轉的特點：
- 解耦性：依賴反轉原則解耦依賴，而控制反轉則解耦流程。
- 主動變被動：對於流程而言，原本需要主動調整計算，現在變成被動獲得答案。
- 易於擴展：新增類別時不需調整流程。
- 易於測試：整個流程更加解耦，自然更容易針對每個物件與步驟進行測試。
依賴注入
如果說控制反轉是一種理念，那麼依賴注入就是實現這個理念的具體方式。
依賴注入可以根據注入的時機分為三種方式：建構元注入、設值方法注入以及介面注入。根據注入的生命週期，又可以分為 Transient（一次性）、Scoped（作用域）與 Singleton（單例）。
以 Laravel 框架為例，由於可以直接在 AppServiceProvider 類別中使用 register 方法，最常使用的方式通常是將 Singleton 與建構元注入搭配使用，也就是我們一開始引言中提到的注入方式喔！
參考資料
留言0
查看全部
你可能也想看
Google News 追蹤
這一章節旨在介紹 PHP 中的物件導向編程（OOP）概念。通過詳細講解類別、建構子、訪問修飾符（公開、私有、受保護）、繼承、多型、封裝、介面、抽象類別、靜態類別、列舉、委派、Lambda 表達式、泛型和反射等概念，使讀者能夠理解和應用這些 OOP 技術來編寫更具結構性和可維護性的 PHP 代碼。
※ 原本狀態：伺服器渲染
這是 MVC 架構下的 request / response 示意圖，在這張圖呈現的架構裡，畫面和資料都由同一個架構處理。
伺服器渲染流程：
瀏覽器針對特定網址送出請求。
路由器解析請求後，轉接給對應的 controller。
controller 按照要求，透過
※ OPP第一大核心-封裝
封裝的精神在於將「方法」、「屬性」和「邏輯」包裝在類別裡面，透過類別的實例來實現。這樣外部物件不需要了解內部的實現細節，只需要知道如何使用該類別提供的接口即可。換句話說，封裝是將內部細節隱藏起來，只暴露必要的部分給使用者。
封裝的核心概念是，使用者如果想要接觸資料，只
一般而言，組件之間的資料傳遞，可以使用 props 來達成，不過一旦層級過多的時候，props 就要逐層向下傳遞，會越來越麻煩且複雜。
而 provide、inject 可以解決這個問題，它可以提供一個「源頭」，子組件們可以藉由同一個源頭取得對應的資料，且沒有層級分別，都可以取得，就不用逐層傳遞資
代理模式通過封裝原始對象來實現對該對象的控制和管理，同時不改變原始對象的行為或客戶端與該對象互動的方式，以此介入或增強對該對象的訪問和操作。
在物件導向程式設計的進階階段，學生將學習繼承、介面、抽象類別等核心概念。繼承允許類別共享屬性和方法，介面確保實現類別提供特定的方法實現，而抽象類別定義了基本結構供子類別擴展。這些知識點有助於提升程式碼的重用性、擴展性和維護性。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
讓我在這篇文章總結一下前面對物件導向設計的討論，我們討論了物件導向的四個特性：繼承、抽象、多型、封裝，分析了它們的問題，並跟函數式編程的思維做比較。我們引入了與之相對應的特性：泛型、特性系統、模組化，有些特性雖然跟那四個特性很像，但在一些細微的地方有不同的詮釋，使得整體思考方式很不一樣。
「繼
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相
這一章節旨在介紹 PHP 中的物件導向編程（OOP）概念。通過詳細講解類別、建構子、訪問修飾符（公開、私有、受保護）、繼承、多型、封裝、介面、抽象類別、靜態類別、列舉、委派、Lambda 表達式、泛型和反射等概念，使讀者能夠理解和應用這些 OOP 技術來編寫更具結構性和可維護性的 PHP 代碼。
※ 原本狀態：伺服器渲染
這是 MVC 架構下的 request / response 示意圖，在這張圖呈現的架構裡，畫面和資料都由同一個架構處理。
伺服器渲染流程：
瀏覽器針對特定網址送出請求。
路由器解析請求後，轉接給對應的 controller。
controller 按照要求，透過
※ OPP第一大核心-封裝
封裝的精神在於將「方法」、「屬性」和「邏輯」包裝在類別裡面，透過類別的實例來實現。這樣外部物件不需要了解內部的實現細節，只需要知道如何使用該類別提供的接口即可。換句話說，封裝是將內部細節隱藏起來，只暴露必要的部分給使用者。
封裝的核心概念是，使用者如果想要接觸資料，只
一般而言，組件之間的資料傳遞，可以使用 props 來達成，不過一旦層級過多的時候，props 就要逐層向下傳遞，會越來越麻煩且複雜。
而 provide、inject 可以解決這個問題，它可以提供一個「源頭」，子組件們可以藉由同一個源頭取得對應的資料，且沒有層級分別，都可以取得，就不用逐層傳遞資
代理模式通過封裝原始對象來實現對該對象的控制和管理，同時不改變原始對象的行為或客戶端與該對象互動的方式，以此介入或增強對該對象的訪問和操作。
在物件導向程式設計的進階階段，學生將學習繼承、介面、抽象類別等核心概念。繼承允許類別共享屬性和方法，介面確保實現類別提供特定的方法實現，而抽象類別定義了基本結構供子類別擴展。這些知識點有助於提升程式碼的重用性、擴展性和維護性。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
讓我在這篇文章總結一下前面對物件導向設計的討論，我們討論了物件導向的四個特性：繼承、抽象、多型、封裝，分析了它們的問題，並跟函數式編程的思維做比較。我們引入了與之相對應的特性：泛型、特性系統、模組化，有些特性雖然跟那四個特性很像，但在一些細微的地方有不同的詮釋，使得整體思考方式很不一樣。
「繼
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相