不改變類別程式碼的情況下擴充該類別功能？

先上圖

目前應用採用的是yaf框架，所有的控制器都繼承自Base_controller， 但由於後期功能越來越多(權限管理、產品管理、日誌管理等)，導致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

不能充當被裝飾者的角色，

所以

Base_controller不能充當被裝飾者的角色，

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

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

使用php的trait

謝邀。

樓上說的 Trait 確實是一個方案，不過問題的關鍵可能不在這裡。 🎜你對裝飾模式的理解雖然不準確但是問題不大，也不是關鍵🎜 🎜我在實際開發中從未遇到過BaseController被搞得很臃腫的問題，通常這是開發人員的水平（或者說境界）導致的結果，別說不改變類代碼，就算改變類代碼這個問題也解決不了，而是要重構。 🎜 🎜通常BaseController臃腫是因為很多不應該由Controller提供的方法被聲明導致的，這些方法可能應該在Model中聲明，或者屬於Helper，這才是關鍵的問題。 Model是共用的，所以其方法在任何Controller中都能使用。而如果本應Model定義的方法被放到了Controller中，而Controller不是公用的，此時的最簡單的解決方式就是放到Base裡面了，長期累積下來就是你現在看到的結果。 🎜