[php] 如果單身人士不好,那麼服務容器為什麼好?



Answers

服務定位器模式是反模式。 它不能解決暴露依賴性的問題(你不能通過查看類的定義來判斷它的依賴關係是什麼,因為它們沒有被注入,而是被從服務定位器中抽出)。

所以,你的問題是:服務定位器為什麼好? 我的回答是:他們不是。

避免,避免,避免。

Question

我們都知道單身人士有多糟糕 ,因為他們隱藏了依賴關係和其他原因

但是在一個框架中,可能有很多對像只需要實例化一次,並從任何地方調用(記錄器,db等)。

為了解決這個問題,我被告知使用所謂的“對像管理器”(或像symfony這樣的服務容器 ),它在內部存儲對服務(記錄器等)的每個引用。

但為什麼服務提供商不像純粹的單身人士那樣糟糕?

服務提供商也隱藏了依賴關係,他們只是將第一次創建包裝起來。 所以我很努力地理解為什麼我們應該使用服務提供者而不是單身人士。

PS。 我知道,為了不隱藏依賴關係,我應該使用DI(如Misko所述)

我想補充一句:現在單身人士並不是那麼邪惡,PHPUnit的創造者在這裡解釋了它:

DI + Singleton解決了這個問題:

<?php
class Client {

    public function doSomething(Singleton $singleton = NULL){

        if ($singleton === NULL) {
            $singleton = Singleton::getInstance();
        }

        // ...
    }
}
?>

即使這並不能解決所有問題,這也是非常聰明的。

除DI和服務容器之外, 有沒有什麼好的可接受的解決方案來訪問這個幫助對象?




因為你可以很容易地通過替換服務容器中的對象
1)繼承(對像管理器類可以繼承,方法可以被重寫)
2)改變配置(在Symfony的情況下)

而且,單身人士不僅因為高度的偶合,而且因為他們是單身 。 幾乎所有類型的對像都是錯誤的架構。

使用'純粹'DI(在構造函數中),您將付出非常大的代價 - 所有對像都應該在構造函數中傳遞之前創建。 這將意味著更多的使用內存和更少的性能。 另外,並不總是可以在構造函數中創建和傳遞對象 - 可以創建依賴關係鏈...我的英語不夠完整,請在Symfony文檔中閱讀它。




Related