4 回答

TA貢獻(xiàn)1794條經(jīng)驗(yàn) 獲得超8個(gè)贊
- 首先糾正一點(diǎn),
MVC
只是大部分WEB
應(yīng)用的一種結(jié)構(gòu)(算是設(shè)計(jì)框架的一種指導(dǎo)性的原則),它本身與你所說的命名空間namespace
(確切地說它屬于一種新的技術(shù),新的特性)就是兩個(gè)維度的東西,所以兩者并不能對(duì)等地去比較。換句話說,當(dāng)前大部分的框架會(huì)采用MVC
的原則去設(shè)計(jì)代碼架構(gòu),而namespace
是當(dāng)前PHP
開發(fā)過程中普遍使用的一種技術(shù)。- 你所描述的第一種方式按我的理解應(yīng)該算
OPP
的開發(fā)(上來就是function
,那么應(yīng)該沒有封裝在類內(nèi))。而用類進(jìn)行了封裝可以算是OOP
的開發(fā)方式。而要達(dá)到你所說的“用最不多余的方式引入需要的功能”其實(shí)也跟這兩者沒有太大的關(guān)系。。當(dāng)你以適當(dāng)?shù)姆绞綄?duì)方法(函數(shù))進(jìn)行拆分和組合之后總會(huì)找到你所想要達(dá)到的效果。。OPP
的方式下你只能采用require
或者include
之類的方式去加載你需要的文件和函數(shù),文件之間的依賴關(guān)系需要你手動(dòng)去維護(hù)。而一般的OOP
下,類之間的依賴關(guān)系也還是需要你手動(dòng)維護(hù),所以它們之間并沒有質(zhì)的區(qū)別,所以也就說不上具體的優(yōu)劣。- 接下來呢,分析一下你具體的疑惑,你所拋出來的問題其實(shí)很龐大,龐大到這可以算是一個(gè)可以研究的課題。。以“最不多余的方式引入需要的功能”其實(shí)反過來說何嘗不是“找到最優(yōu)的方式提高代碼的復(fù)用度,降低冗余”。很多的設(shè)計(jì)模式都需要與實(shí)際問題相結(jié)合來實(shí)現(xiàn)這樣的目標(biāo)。你所描述的“根據(jù)路由器來決定要引入哪些類”似乎傳達(dá)的是依賴注入(Denpdency Injection, DI)。依賴注入本質(zhì)上它還是類的調(diào)用,但是它將類的依賴關(guān)系交給依賴注入容器來管理。你可以自己詳細(xì)看一下
DIP
,IoC
還有DI
,應(yīng)該就能理解了。另外你還可以自己嘗試設(shè)計(jì)Interface
、abstract
之類的再輔以trait
來正向地初步實(shí)現(xiàn)你需要的效果。。

TA貢獻(xiàn)1820條經(jīng)驗(yàn) 獲得超10個(gè)贊
很明顯,直接引用的話,寫的代碼少,而且內(nèi)存消耗,執(zhí)行效率肯定是最好的。
但是帶來的最大的壞處就是,你寫了1000個(gè)function后你會(huì)發(fā)現(xiàn),你的項(xiàng)目已經(jīng)不能維護(hù)了,因?yàn)槟阋氤?000個(gè)函數(shù)名,
其實(shí)對(duì)于php來說,不用框架,php的運(yùn)行效率是最高的,但是不用框架,代碼可維護(hù)性太差了,這個(gè)就是運(yùn)行效率和開發(fā)效率的考量了

TA貢獻(xiàn)1775條經(jīng)驗(yàn) 獲得超8個(gè)贊
維護(hù)性、可擴(kuò)展性并不高,出現(xiàn)bug后原因查找也非常困難。
沒有“銀彈”,設(shè)計(jì)模式是這些年來資深開發(fā)者通過實(shí)現(xiàn)不同需求自我總結(jié)出來的。類的概念即是其中之一。

TA貢獻(xiàn)1848條經(jīng)驗(yàn) 獲得超6個(gè)贊
直接函數(shù)編程是PHP最原始的編寫方式:
優(yōu)點(diǎn):是簡(jiǎn)單直接
缺點(diǎn):中大型項(xiàng)目維護(hù)成本很高,不利于擴(kuò)展
以類的方式+include方式是面向?qū)ο箝_發(fā)的結(jié)果:
優(yōu)點(diǎn):類可以隔離變量以及方法
缺點(diǎn):不管是否需要都會(huì)include文件,浪費(fèi)資源,且引入第三方庫的情況下,無法保證類名是否重復(fù)
類+命名空間+自動(dòng)導(dǎo)入:推薦的開發(fā)方式,自動(dòng)加載類可完全不用自己include文件,方便中大型項(xiàng)目開發(fā)和維護(hù)。
- 4 回答
- 0 關(guān)注
- 368 瀏覽
添加回答
舉報(bào)