laravel 學習筆記 —— 神奇的服務容器

容器，字面上理解就是裝東西的東西。常見的變量、對象屬性等都可以算是容器。一個容器能夠裝什麼，全部取決於你對該容器的定義。當然，有這樣一種容器，它存放的不是文本、數值，而是對象、對象的描述（類、接口）或者是提供對象的回調，通過這種容器，我們得以實現許多高級的功能，其中最常提到的，就是 “解耦” 、“依賴注入（DI）”。本文就從這裏開始。

IoC 容器， laravel 的核心

Laravel 的核心就是一個 IoC 容器，根據文檔，稱其爲“服務容器”，顧名思義，該容器提供了整個框架中需要的一系列服務。作爲初學者，很多人會在這一個概念上犯難，因此，我打算從一些基礎的內容開始講解，通過理解面向對象開發中依賴的產生和解決方法，來逐漸揭開“依賴注入”的面紗，逐漸理解這一神奇的設計理念。

本文一大半內容都是通過舉例來讓讀者去理解什麼是 IoC（控制反轉） 和 DI（依賴注入），通過理解這些概念，來更加深入。更多關於 laravel 服務容器的用法建議閱讀文檔即可。

IoC 容器誕生的故事

講解 IoC 容器有很多的文章，我之前也寫過。但現在我打算利用當下的靈感重新來過，那麼開始吧。

超人和超能力，依賴的產生！

面向對象編程，有以下幾樣東西無時不刻的接觸：接口、類還有對象。這其中，接口是類的原型，一個類必須要遵守其實現的接口；對象則是一個類實例化後的產物，我們稱其爲一個實例。當然這樣說肯定不利於理解，我們就實際的寫點中看不中用的代碼輔助學習。

怪物橫行的世界，總歸需要點超級人物來擺平。

我們把一個“超人”作爲一個類，

class Superman {}

我們可以想象，一個超人誕生的時候肯定擁有至少一個超能力，這個超能力也可以抽象爲一個對象，爲這個對象定義一個描述他的類吧。一個超能力肯定有多種屬性、（操作）方法，這個盡情的想象，但是目前我們先大致定義一個只有屬性的“超能力”，至於能幹啥，我們以後再豐富：

class Power {
    /**
     * 能力值
     */
    protected $ability;
 
    /**
     * 能力範圍或距離
     */
    protected $range;
 
    public function __construct($ability, $range)
    {
        $this->ability = $ability;
        $this->range = $range;
    }
}

這時候我們回過頭，修改一下之前的“超人”類，讓一個“超人”創建的時候被賦予一個超能力：

class Superman
{
    protected $power;
 
    public function __construct()
    {
        $this->power = new Power(999, 100);
    }
}

這樣的話，當我們創建一個“超人”實例的時候，同時也創建了一個“超能力”的實例，但是，我們看到了一點，“超人”和“超能力”之間不可避免的產生了一個依賴。

所謂“依賴”，就是 “我若依賴你，我就不能離開你”。

在一個貫徹面向對象編程的項目中，這樣的依賴隨處可見。少量的依賴並不會有太過直觀的影響，我們隨着這個例子逐漸鋪開，讓大家慢慢意識到，當依賴達到一個量級時，是怎樣一番噩夢般的體驗。當然，我也會自然而然的講述如何解決問題。

一堆亂麻 —— 可怕的依賴

之前的例子中，超能力類實例化後是一個具體的超能力，但是我們知道，超人的超能力是多元化的，每種超能力的方法、屬性都有不小的差異，沒法通過一種類描述完全。我們現在進行修改，我們假設超人可以有以下多種超能力：

飛行，屬性有：飛行速度、持續飛行時間
蠻力，屬性有：力量值
能量彈，屬性有：傷害值、射擊距離、同時射擊個數

我們創建瞭如下類：

class Flight
{
    protected $speed;
    protected $holdtime;
    public function __construct($speed, $holdtime) {}
}
 
class Force
{
    protected $force;
    public function __construct($force) {}
}
 
class Shot
{
    protected $atk;
    protected $range;
    protected $limit;
    public function __construct($atk, $range, $limit) {}
}

*爲了省事兒我沒有詳細寫出 __construct() 這個構造函數的全部，只寫了需要傳遞的參數。

好了，這下我們的超人有點“忙”了。在超人初始化的時候，我們會根據需要來實例化其擁有的超能力嗎，大致如下：

class Superman
{
    protected $power;
 
    public function __construct()
    {
        $this->power = new Fight(9, 100);
        // $this->power = new Force(45);
        // $this->power = new Shot(99, 50, 2);
        /*
        $this->power = array(
            new Force(45),
            new Shot(99, 50, 2)
        );
        */
    }
}

我們需要自己手動的在構造函數內（或者其他方法裏）實例化一系列需要的類，這樣並不好。可以想象，假如需求變更（不同的怪物橫行地球），需要更多的有針對性的新的超能力，或者需要變更超能力的方法，我們必須 重新改造 超人。換句話說就是，改變超能力的同時，我還得重新制造個超人。效率太低了！新超人還沒創造完成世界早已被毀滅。

這時，靈機一動的人想到：爲什麼不可以這樣呢？超人的能力可以被隨時更換，只需要添加或者更新一個芯片或者其他裝置啥的（想到鋼鐵俠沒）。這樣的話就不要整個重新來過了。

對，就是這樣的。

我們不應該手動在 “超人” 類中固化了他的 “超能力” 初始化的行爲，而轉由外部負責，由外部創造超能力模組、裝置或者芯片等（我們後面統一稱爲 “模組”），植入超人體內的某一個接口，這個接口是一個既定的，只要這個 “模組” 滿足這個接口的裝置都可以被超人所利用，可以提升、增加超人的某一種能力。這種由外部負責其依賴需求的行爲，我們可以稱其爲 “控制反轉（IoC）”。

工廠模式，依賴轉移！

當然，實現控制反轉的方法有幾種。在這之前，不如我們先了解一些好玩的東西。

我們可以想到，組件、工具（或者超人的模組），是一種可被生產的玩意兒，生產的地方當然是 “工廠（Factory）”，於是有人就提出了這樣一種模式： 工廠模式。

工廠模式，顧名思義，就是一個類所依賴的外部事物的實例，都可以被一個或多個 “工廠” 創建的這樣一種開發模式，就是 “工廠模式”。

我們爲了給超人制造超能力模組，我們創建了一個工廠，它可以製造各種各樣的模組，且僅需要通過一個方法：

class SuperModuleFactory
{
    public function makeModule($moduleName, $options)
    {
        switch ($moduleName) {
            case 'Fight':   return new Fight($options[0], $options[1]);
            case 'Force':   return new Force($options[0]);
            case 'Shot':    return new Shot($options[0], $options[1], $options[2]);
        }
    }
}

這時候，超人創建之初就可以使用這個工廠！

class Superman
{
    protected $power;
 
    public function __construct()
    {
        // 初始化工廠
        $factory = new SuperModuleFactory;
 
        // 通過工廠提供的方法制造需要的模塊
        $this->power = $factory->makeModule('Fight', [9, 100]);
        // $this->power = $factory->makeModule('Force', [45]);
        // $this->power = $factory->makeModule('Shot', [99, 50, 2]);
        /*
        $this->power = array(
            $factory->makeModule('Force', [45]),
            $factory->makeModule('Shot', [99, 50, 2])
        );
        */
    }
}

可以看得出，我們不再需要在超人初始化之初，去初始化許多第三方類，只需初始化一個工廠類，即可滿足需求。但這樣似乎和以前區別不大，只是沒有那麼多 new 關鍵字。其實我們稍微改造一下這個類，你就明白，工廠類的真正意義和價值了。

class Superman
{
    protected $power;
 
    public function __construct(array $modules)
    {
        // 初始化工廠
        $factory = new SuperModuleFactory;
 
        // 通過工廠提供的方法制造需要的模塊
        foreach ($modules as $moduleName => $moduleOptions) {
            $this->power[] = $factory->makeModule($moduleName, $moduleOptions);
        }
    }
}
 
// 創建超人
$superman = new Superman([
    'Fight' => [9, 100], 
    'Shot' => [99, 50, 2]
    ]);

現在修改的結果令人滿意。現在，“超人” 的創建不再依賴任何一個 “超能力” 的類，我們如若修改了或者增加了新的超能力，只需要針對修改 SuperModuleFactory 即可。擴充超能力的同時不再需要重新編輯超人的類文件，使得我們變得很輕鬆。但是，這纔剛剛開始。

再進一步！IoC 容器的重要組成 —— 依賴注入！

由 “超人” 對 “超能力” 的依賴變成 “超人” 對 “超能力模組工廠” 的依賴後，對付小怪獸們變得更加得心應手。但這也正如你所看到的，依賴並未解除，只是由原來對多個外部的依賴變成了對一個 “工廠” 的依賴。假如工廠出了點麻煩，問題變得就很棘手。

其實大多數情況下，工廠模式已經足夠了。工廠模式的缺點就是：接口未知（即沒有一個很好的契約模型，關於這個我馬上會有解釋）、產生對象類型單一。總之就是，還是不夠靈活。雖然如此，工廠模式依舊十分優秀，並且適用於絕大多數情況。不過我們爲了講解後面的 依賴注入 ，這裏就先誇大一下工廠模式的缺陷咯。

我們知道，超人依賴的模組，我們要求有統一的接口，這樣才能和超人身上的注入接口對接，最終起到提升超能力的效果。

事實上，我之前說謊了，不僅僅只有一堆小怪獸，還有更多的大怪獸。嘿嘿。額，這時候似乎工廠的生產能力顯得有些不足 —— 由於工廠模式下，所有的模組都已經在工廠類中安排好了，如果有新的、高級的模組加入，我們必須修改工廠類（好比增加新的生產線）：

class SuperModuleFactory
{
    public function makeModule($moduleName, $options)
    {
        switch ($moduleName) {
            case 'Fight':   return new Fight($options[0], $options[1]);
            case 'Force':   return new Force($options[0]);
            case 'Shot':    return new Shot($options[0], $options[1], $options[2]);
            // case 'more': .......
            // case 'and more': .......
            // case 'and more': .......
            // case 'oh no! its too many!': .......
        }
    }
}

看到沒。。。噩夢般的感受！

其實靈感就差一步！你可能會想到更爲靈活的辦法！對，下一步就是我們今天的主要配角 —— DI （依賴注入）

由於對超能力模組的需求不斷增大，我們需要集合整個世界的高智商人才，一起解決問題，不應該僅僅只有幾個工廠壟斷負責。不過高智商人才們都非常自負，認爲自己的想法是對的，創造出的超能力模組沒有統一的接口，自然而然無法被正常使用。這時我們需要提出一種契約，這樣無論是誰創造出的模組，都符合這樣的接口，自然就可被正常使用。

interface SuperModuleInterface
{
    /**
     * 超能力激活方法
     *
     * 任何一個超能力都得有該方法，並擁有一個參數
     *@param array $target 針對目標，可以是一個或多個，自己或他人
     */
    public function activate(array $target);
}

上文中，我們定下了一個接口（超能力模組的規範、契約），所有被創造的模組必須遵守該規範，才能被生產。

其實，這就是 php 中 接口（ interface ） 的用處和意義！很多人覺得，爲什麼 php 需要接口這種東西？難道不是 java 、 C# 之類的語言纔有的嗎？這麼說，只要是一個正常的面向對象編程語言（雖然 php 可以面向過程），都應該具備這一特性。因爲一個 對象（object） 本身是由他的模板或者原型 —— 類（class） ，經過實例化後產生的一個具體事物，而有時候，實現統一種方法且不同功能（或特性）的時候，會存在很多的類（class），這時候就需要有一個契約，讓大家編寫出可以被隨時替換卻不會產生影響的接口。這種由編程語言本身提出的硬性規範，會增加更多優秀的特性。

雖然有些繞，但通過我們接下來的實例，大家會慢慢領會接口帶來的好處。

這時候，那些提出更好的超能力模組的高智商人才，遵循這個接口，創建了下述（模組）類：

/**
 * X-超能量
 */
class XPower implements SuperModuleInterface
{
    public function activate(array $target)
    {
        // 這只是個例子。。具體自行腦補
    }
}
 
/**
 * 終極炸彈 （就這麼俗）
 */
class UltraBomb implements SuperModuleInterface
{
    public function activate(array $target)
    {
        // 這只是個例子。。具體自行腦補
    }
}

同時，爲了防止有些 “磚家” 自作聰明，或者一些叛徒惡意搗蛋，不遵守契約胡亂製造模組，影響超人，我們對超人初始化的方法進行改造：

class Superman
{
    protected $module;
 
    public function __construct(SuperModuleInterface $module)
    {
        $this->module = $module
    }
}

改造完畢！現在，當我們初始化 “超人” 類的時候，提供的模組實例必須是一個SuperModuleInterface 接口的實現。否則就會提示錯誤。

正是由於超人的創造變得容易，一個超人也就不需要太多的超能力，我們可以創造多個超人，並分別注入需要的超能力模組即可。這樣的話，雖然一個超人只有一個超能力，但超人更容易變多，我們也不怕怪獸啦！

現在有人疑惑了，你要講的 依賴注入 呢？

其實，上面講的內容，正是依賴注入。

什麼叫做 依賴注入？

本文從開頭到現在提到的一系列依賴，只要不是由內部生產（比如初始化、構造函數__construct 中通過工廠方法、自行手動 new 的），而是由外部以參數或其他形式注入的，都屬於 依賴注入（DI） 。是不是豁然開朗？事實上，就是這麼簡單。下面就是一個典型的依賴注入：

// 超能力模組
$superModule = new XPower;
 
// 初始化一個超人，並注入一個超能力模組依賴
$superMan = new Superman($superModule);

關於依賴注入這個本文的主要配角，也就這麼多需要講的。理解了依賴注入，我們就可以繼續深入問題。慢慢走近今天的主角……

更爲先進的工廠 —— IoC 容器！

剛剛列了一段代碼：

$superModule = new XPower;
 
$superMan = new Superman($superModule);

讀者應該看出來了，手動的創建了一個超能力模組、手動的創建超人並注入了剛剛創建超能力模組。呵呵，手動。

現代社會，應該是高效率的生產，乾淨的車間，完美的自動化裝配。

一羣怪獸來了，如此低效率產出超人是不現實，我們需要自動化 —— 最多一條指令，千軍萬馬來相見。我們需要一種高級的生產車間，我們只需要向生產車間提交一個腳本，工廠便能夠通過指令自動化生產。這種更爲高級的工廠，就是工廠模式的昇華 —— IoC 容器。

class Container
{
    protected $binds;
 
    protected $instances;
 
    public function bind($abstract, $concrete)
    {
        if ($concrete instanceof Closure) {
            $this->binds[$abstract] = $concrete;
        } else {
            $this->instances[$abstract] = $concrete;
        }
    }
 
    public function make($abstract, $parameters = [])
    {
        if (isset($this->instances[$abstract])) {
            return $this->instances[$abstract];
        }
 
        array_unshift($parameters, $this);
 
        return call_user_func_array($this->binds[$abstract], $parameters);
    }
}

這時候，一個十分粗糙的容器就誕生了。現在的確很簡陋，但不妨礙我們進一步提升他。先着眼現在，看看這個容器如何使用吧！

// 創建一個容器（後面稱作超級工廠）
$container = new Container;
 
// 向該 超級工廠 添加 超人 的生產腳本
$container->bind('superman', function($container, $moduleName) {
    return new Superman($container->make($moduleName));
});
 
// 向該 超級工廠 添加 超能力模組 的生產腳本
$container->bind('xpower', function($container) {
    return new XPower;
});
 
// 同上
$container->bind('ultrabomb', function($container) {
    return new UltraBomb;
});
 
// ******************  華麗麗的分割線  **********************
// 開始啓動生產
$superman_1 = $container->make('superman', ['xpower']);
$superman_2 = $container->make('superman', ['ultrabomb']);
$superman_3 = $container->make('superman', ['xpower']);
// ...隨意添加

看到沒？通過最初的 綁定（bind） 操作，我們向超級工廠註冊了一些生產腳本，這些生產腳本在生產指令下達之時便會執行。發現沒有？我們徹底的解除了超人與超能力模組的依賴關係，更重要的是，容器類也絲毫沒有和他們產生任何依賴！我們通過註冊、綁定的方式向容器中添加一段可以被執行的回調（可以是匿名函數、非匿名函數、類的方法）作爲生產一個類的實例的腳本，只有在真正的 生產（make） 操作被調用執行時，纔會觸發。

這樣一種方式，使得我們更容易在創建一個實例的同時解決其依賴關係，並且更加靈活。當有新的需求，只需另外綁定一個“生產腳本”即可。

實際上，真正的 IoC 容器更爲高級。我們現在的例子中，還是需要手動提供超人所需要的模組參數，但真正的 IoC 容器會根據類的依賴需求，自動在註冊、綁定的一堆實例中搜尋符合的依賴需求，並自動注入到構造函數參數中去。Laravel 框架的服務容器正是這麼做的。實現這種功能其實理論上並不麻煩，但我並不會在本文中寫出，因爲……我懶得寫。

不過我告訴大家，這種自動搜尋依賴需求的功能，是通過 反射（Reflection） 實現的，恰好的，php 完美的支持反射機制！關於反射，php 官方文檔有詳細的資料，並且中文翻譯基本覆蓋，足夠學習和研究！

http://php.net/manual/zh/book.reflection.php

現在，到目前爲止，我們已經不再懼怕怪獸們了。高智商人才集思廣益，井井有條，根據接口契約創造規範的超能力模組。超人開始批量產出。最終，人人都是超人，你也可以是哦！

迴歸正常世界。我們開始重新審視 laravel 的核心。

現在，我們開始慢慢解讀 laravel 的核心。其實，laravel 的核心就是一個 IoC 容器，也恰好是我之前所說的高級的 IoC 容器。

可以說，laravel 的核心本身十分輕量，並沒有什麼很神奇很實質性的應用功能。很多人用到的各種功能模塊比如 Route（路由）、Eloquent ORM（數據庫 ORM 組件）、Request and Response（請求和響應）等等等等，實際上都是與核心無關的類模塊提供的，這些類從註冊到實例化，最終被你所使用，其實都是 laravel 的服務容器負責的。

我們以大家最常見的 Route 類作爲例子。大家可能經常見到路由定義是這樣的：

Route::get('/', function() {
    // bla bla bla...
});

實際上， Route 類被定義在這個命名空間：Illuminate\Routing\Router，文件vendor/laravel/framework/src/Illuminate/Routing/Router.php。

我們通過打開發現，這個類的這一系列方法，如 get，post，any 等都不是靜態（static）方法，這是怎麼一回事兒？不要急，我們繼續。

服務提供者

我們在前文介紹 IoC 容器的部分中，提到了，一個類需要綁定、註冊至容器中，才能被“製造”。

對，一個類要被容器所能夠提取，必須要先註冊至這個容器。既然 laravel 稱這個容器叫做服務容器，那麼我們需要某個服務，就得先註冊、綁定這個服務到容器，那麼提供服務並綁定服務至容器的東西，就是 服務提供者（ServiceProvider）。

雖然，綁定一個類到容器不一定非要通過 服務提供者（ServiceProvider） 。

但是，我們知道，有時候我們的類、模塊會有需要其他類和組件的情況，爲了保證初始化階段不會出現所需要的模塊和組件沒有註冊的情況，laravel 將註冊和初始化行爲進行拆分，註冊的時候就只能註冊，初始化的時候就是初始化。拆分後的產物就是現在的服務提供者。

服務提供者主要分爲兩個部分，register（註冊） 和 boot（引導、初始化），具體參考文檔。register 負責進行向容器註冊“腳本”，但要注意註冊部分不要有對未知事物的依賴，如果有，就要移步至 boot 部分。

Facade

我們現在解答之前關於 Route 的方法爲何能以靜態方法訪問的問題。實際上這個問題文檔上有寫，簡單說來就是模擬一個類，提供一個靜態魔術方法__callStatic，並將該靜態方法映射到真正的方法上。

我們使用的 Route 類實際上是 Illuminate\Support\Facades\Route 通過class_alias() 函數創造的 別名 而已，這個類被定義在文件vendor/laravel/framework/src/Illuminate/Support/Facades/Route.php 。

我們打開文件一看……誒？怎麼只有這麼簡單的一段代碼呢？

<?php namespace Illuminate\Support\Facades;
 
/**
 * @see \Illuminate\Routing\Router
 */
class Route extends Facade {
 
    /**
     * Get the registered name of the component.
     *
     * @return string
     */
    protected static function getFacadeAccessor()
    {
        return 'router';
    }
 
}

其實仔細看，會發現這個類繼承了一個叫做 Facade 的類，到這裏謎底差不多要解開了。

上述簡單的定義中，我們看到了 getFacadeAccessor 方法返回了一個 route，這是什麼意思呢？事實上，這個值被一個 ServiceProvider 註冊過，大家應該知道註冊了個什麼，當然是那個真正的路由類！

有人會問，Facade 是怎麼實現的。我並不想說得太細，一個是我懶，另一個原因就是，自己發現一些東西更容易理解，並不容易忘記。很多細節我已經說了，建議大家自行去研究。

至此，我們已經講的差不多了。

和平！我們該總結總結了！

無論如何，世界和平了。

這裏要總結的內容就是，其實很多事情並不複雜，怕的是複雜的理論內容。我覺得很多東西一旦想通也就那麼回事兒。很多人覺得 laravel 這不好那不好、這裏難哪裏難，我只能說，laravel 的確不是一流和優秀的框架，說 laravel 是一流、優秀的框架的人，不是 laravel 的粉絲那麼就是跟風炒作。Laravel 最大的特點和優秀之處就是使用了很多 php 比較新（實際上並不新）的概念和技術（也就一堆語法糖）而已。因此 laravel 的確符合一個適宜學習的框架。Laravel 的構思的確和其他框架有很大不同，這也要求學習他的人必須熟練 php，並 基礎紮實！如果你覺得學 laravel 框架十分困難，那麼原因只有一個：你 php 基礎不好。

另外，善於利用命名空間和麪向對象的諸多特性，去追尋一些東西，你會發現，原來這一切這麼容易。

原文：https://www.insp.top/article/learn-laravel-container

laravel 學習筆記 —— 神奇的服務容器

IoC 容器， laravel 的核心

IoC 容器誕生的故事

超人和超能力，依賴的產生！

一堆亂麻 —— 可怕的依賴

工廠模式，依賴轉移！

再進一步！IoC 容器的重要組成 —— 依賴注入！

更爲先進的工廠 —— IoC 容器！

迴歸正常世界。我們開始重新審視 laravel 的核心。

服務提供者

Facade

和平！我們該總結總結了！

這個網絡爬蟲代碼，拿到數據之後如何存到csv文件中去？

即刻放大鏡。跟隨鼠標，屏幕任意位置放大

【面試準備】【SQL】數據庫有哪些約束？

.NET開源強大、易於使用的緩存框架 - FusionCache

面試，有時候是個運氣活

PHP魔術方法和魔術常量

laravel 學習筆記——路由（基礎）

laravel 學習筆記 —— 神奇的服務容器

laravel 學習筆記——路由（路由與控制器）

laravel 學習筆記——路由（中間件與路由組）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結