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需要這麼多「設計模式」的主要原因。 一旦有了一等函數，你將不再需要大部分的這些設計模式。

個人意見而已：

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