不改變類代碼的情況下擴充該類功能？

先

目前應用採用的是yaf架構，所有的控制器都繼承自Base_controller， 但由於後期功能越來越多(許可權管理、產品管理、日誌管理等)， 導致Base_controller已經不能再臃腫了，

當然完全可以按不同的功能建立不同的類檔案，然後在Base_controller中初始化也能滿足需求， 但這樣各個功能和Base_controller強耦合， 所以我想有沒有更好的解決方案。

目前我想的是裝飾模式，(因為目前只會這個，媽蛋)，
用具體的裝飾類(許可權管理，日誌管理)來裝飾Base_controller, 使其具有這些功能， 但由於裝飾模式要求被裝飾者(Base_controller), 和具體裝飾者都繼承自同一類， 然而現在Base_controller已經繼承自其它類了， 所以Base_controller不能充當被裝飾者的角色，

那麼我辛辛苦苦寫好的功能類(許可權管理、產品管理、日誌管理)用來裝飾誰呢，

所以是不是我方向錯了， 裝飾模式在這雷根本就不合適， 還是說需要其他的設計？

回複內容：

先

目前應用採用的是yaf架構，所有的控制器都繼承自Base_controller， 但由於後期功能越來越多(許可權管理、產品管理、日誌管理等)， 導致Base_controller已經不能再臃腫了，

當然完全可以按不同的功能建立不同的類檔案，然後在Base_controller中初始化也能滿足需求， 但這樣各個功能和Base_controller強耦合， 所以我想有沒有更好的解決方案。

目前我想的是裝飾模式，(因為目前只會這個，媽蛋)，
用具體的裝飾類(許可權管理，日誌管理)來裝飾Base_controller, 使其具有這些功能， 但由於裝飾模式要求被裝飾者(Base_controller), 和具體裝飾者都繼承自同一類， 然而現在Base_controller已經繼承自其它類了， 所以Base_controller不能充當被裝飾者的角色，

那麼我辛辛苦苦寫好的功能類(許可權管理、產品管理、日誌管理)用來裝飾誰呢，

所以是不是我方向錯了， 裝飾模式在這雷根本就不合適， 還是說需要其他的設計？

使用php的trait

謝邀。

樓上說的 Trait 確實是一個方案，不過問題的關鍵可能不在這裡。
你對裝飾模式的理解雖然不準確但是問題不大，也不是關鍵

我在實際開發中從未遇到過BaseController被搞得很臃腫的問題，通常這是開發人員的水平（或者說境界）導致的結果，別說不改變類代碼，就算改變類代碼這個問題也解決不了，而是要重構。

通常BaseController臃腫是因為很多不應該由Controller提供的方法被聲明導致的，這些方法可能應該在Model中聲明，或者屬於Helper，這才是關鍵的問題。Model是共用的，所以其方法在任何Controller中都能使用。而如果本應Model定義的方法被放到了Controller中，而Controller不是公用的，此時的最簡單的解決方式就是放到Base裡面了，長期累積下來就是你現在看到的結果。

