PHP元件化開發

設計思想中有兩種極端：大而全、小而美。

一般我們常用的庫是小而美，用的架構是大而全。從Symfony實作Component式開發開始，架構的元件化逐漸成為趨勢。我們可以任意的組合各種Compoent來形成自己的PHP架構，比如B團隊出的Db及ORM引擎、B團隊出的緩存引擎、E團隊出的Route映射引擎、C團隊出的DI、D團隊出的MVC、X團隊的單元測試工具。Composer出現後，提供了高度便捷性，加速了這種趨勢。

Yii這個架構是典型的全棧式架構，正常應用開發所需功能幾乎都揉和到一個項目中。yii2到現在，它的核心實作還是以傳統Web應用場景為重心。但這隻是他的形，他的核心思想裡是元件化的，有Component這樣的完善機制，隻是沒有拆開成各個子項目而已。

如何将Yii2這樣的項目拆成Component式的子項目呢，你可以自己想想！

代碼重用據說是OOP思想最想要解決的問題？如果我們寫出的每個功能，抽象的庫、具體的業務子產品，都可以實作最大化獨立和重用，似乎是很美好的一件事情，借助于開源的趨勢，若幹年的積累後，隻要像搭積木一樣組合一下，就可以完成滿足實際需求的應用系統。

請注意上文中的“搭積木”這個詞，搭積木源自于孩童時的遊戲，不同的積木組合可以拼成各種房子、各種車等，但積木組合出來的都是人所處環境的實物，和應用系統這種存在于計算機世界的事物在目前的認知上是完全不同的體系，搭積木這個詞用在應用開發上，合适嗎？

通常我們的結論是這樣：代碼可以以庫的形式重用，重複的功能子產品式開發和引用，但不同的應用有不同的場景，還是需要以比較“巧妙”的方式去定制的，比如“鈎子”、“行為”、“事件”、“插件”等。

話再說回來，元件化可以到什麼程度呢？

市面上成功的CMS等系統都通過“插件”或“擴充”，配合“應用市場”建立了比較強大的開發者生态圈，通過“巧妙”的機制實作具體場景的定制化，滿足使用者的需求。

舉個簡單的例子來說，TP的Model是這樣的：

在具體的Model裡如UserModel，覆寫

這兩個方法以實作資料删除前和删除後觸發的關聯操作，但Yii中，隻要繼承Component基類實作的類，都可以使用事件和行為來擴充原來的邏輯，而且可從外部來定義，非常靈活。

yii中的用法大緻為：

TP的控制器中也有鈎子，應該也算是一種實作方式吧。

庫Component化、業務功能以子產品化的方式實作，就可以實作擴充和定制的無限可能性。