php這樣做有什麼不妥之處呢？

提這個問題的緣由其實是我在知乎上看了這麼一個回答:

PHP編程中有哪些常見的低級錯誤？

http://www.zhihu.com/question...

其中提到的錯誤做法:
把Class當名字空間來用，method就是套了Class的function

這樣做有什麼不妥之處呢？

回複內容：

提這個問題的緣由其實是我在知乎上看了這麼一個回答:

PHP編程中有哪些常見的低級錯誤？

http://www.zhihu.com/question...

其中提到的錯誤做法:
把Class當名字空間來用，method就是套了Class的function

這樣做有什麼不妥之處呢？

用過程式結構化編程就是"思想固化"?我看把"物件導向"當成放之四海而皆準的"萬金油"才是"八股文般的思想固化"吧,甚至提出完全面向對象這種"一刀切極端"的編程要求.我覺得對象思想的最大好處在於封裝,能把相關的函數封裝起來提供給其他人調用,有命名衝突改個類名就行.如果不用類,有命名衝突的時候就需要修改多個函數的首碼了.所以說把類當命名空間用,也沒什麼不妥.

我們就看PHP自身,PHP提供的功能有基於函數和類的兩種封裝,基於函數的封裝有常用的字串操作函數和數組操作函數等,基於類的封裝則有SPL庫等,你會說物件導向就一定比過程式先進和方便麼?我看不見得.如果真的那麼熱衷物件導向,難道不應該是去學所有庫都基於類封裝"完全物件導向"的Java麼?

Java大神王垠看待物件導向編程:

“對象思想”作為資料訪問的方式，是有一定好處的。 然而“物件導向”（多了“面向”兩個字），就是把這種本來良好的思想東拉西扯，牽強附會，發揮過了頭。 很多物件導向語言號稱“所有東西都是對象”，把所有函數都放進所謂對象裡面，叫做“方法”，把普通的函數叫做“靜態方法”。 實際上只有極少需要抽象的時候，需要使用內嵌於對象之內，跟資料緊密結合的“方法”。 其他的時候，你其實只是想表達資料之間的變換操作，這些完全可以用普通的函數表達，而且這樣做更加簡單和直接。 把所有函數放進對象的做法是本末倒置的，因為函數本身並不屬於對象，它們只是對象上面的變換操作。 絕大部分函數是獨立於對象的，它們不能被叫做“方法”。 強制把所有函數放進它們本來不屬於的對象裡面，把它們全都作為“方法”，導致了物件導向代碼邏輯過度複雜。 很簡單的想法，非得繞好多道彎子才能表達清楚。 很多人至今不知道自己所用的“物件導向語言”裡面的很多優點，都是從過程式語言繼承來的。 大多數的物件導向語言裡都缺乏正確的實現一等函數的機制。 Java語言是一個極致，它完全不允許將函數當作資料來傳遞。 你需要將全部的函數都封裝進類，然後稱它們為“方法”，但就像我說的，這是綁架。 缺乏一等函數是為什麼Java裡需要這麼多“設計模式”的主要原因。 一旦有了一等函數，你將不再需要大部分的這些設計模式。

個人意見而已：

最大的不妥就是思想的固化吧，沒能從過程化中走出來，理解不了物件導向編程真正改變的是什麼，物件導向編程真正的優勢在哪，更別說面向介面編程了。

