PHP面向對象之我見
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
PHP由Sapi、Main、Zend和Ext組成,PHP應用由哪些組成?地基+上層建筑。所謂地基就是各個應用間共有的那些部分,像現在流行的很多PHP框架就是試圖給你打個地基。我不大喜歡別人給我打地基,所以平時都是自己打地基,自己打的地基牢與不牢自己最清楚。我爸是個建筑家,他建房子的能力在我們小鎮也是赫赫有名了,從小耳濡目染,導致我也對打地基搞建筑很感興趣,現在把這股勁弄到打軟件地基上來,看能打出個啥地基出來,嘿嘿。 本文摘自《草根》雜志第三期 -- http://www.lampbrother.net/grassroots/ 這個地基應該怎么打?說實話這非常依賴經驗。純理論派的家伙,別看他口若懸河講起理論來滔滔不絕,你一讓他給你寫一個出來看看,他立馬消失;純實戰派的家伙怎么樣,對比想象一下便知,在此不在廢話。我不喜歡蠻干,所以我推崇的是中庸之道:理論與實踐相結合。 看過一堆框架后相信很多人多少都對什么控制器、視圖、模型之類的東西有點熟悉了,在此也不多說。我想說的是,把眼光放遠一點,放靈活一點,放實際一點。又遠又實際?這不是矛盾么?那可未必。面向對象是不是較新的開發方式?看著那么多粉絲前撲后繼“奔向”軟件開發的“真理”,我倒開始打退堂鼓。當然,你可以認為我面向對象能力不過關:)然而翻開《人月神話》,感受一下真正的大師對面向對象開發方式的淡然的態度,我忽然覺得以前對面向對象開發的狂熱是多么幼稚…… 實際上我想說的是,面向對象不過是一種普通的軟件開發方式,而且它的名字取得很莫名其妙,什么是“面向”對象?為什么是“面向”而不是“背向”?這很滑稽,所以我寧愿稱之為“對象化”編程,以跟“結構化”編程相對應。對象又多少種呢?在PHP里,基礎設施大部分是地基對象。注意,我說的是“對象”,而不是“類”。我很反感討論對象時把類扯進來。PHP程序的一次運行就像一個士兵到一個城堡內送一封信,得到城主的處理后把結果送回,從進城門到出城門這一過程就是PHP腳本的執行過程。它的本質就是“過程”,不認識這個本質的設計注定是失敗的。這個過程你會怎么設計?這就跟打基礎一樣啦。你會想,可能會有兩個士兵守城門,進了城門后有向導,向導會問你有什么事,然后告訴你怎么走,走到目的地后又有士兵攔住你要證明,通過證明后才讓你進入辦事處,然后才是實際的事務,完成事務后一路返回,向各個守衛告別,最后離開城門:整個過程就是PHP腳本的執行過程。 發覺我經常走題萬里,看,什么是靈活一點什么是實際一點,怎么打地基,都跑九霄云外去了,抱歉抱歉。實際上靈活、實際等概念跟其它眾多優秀設計理念完全是融合在一起的,不好單獨抽出來說明而不涉及其它概念,但基于這些互相融合的概念,設計出來的系統卻是非常靈活的系統,具有非常低的互相糾纏關系,用術語說,是“耦合”關系。“零件”是極富表現力的隱喻,一個系統的動作都是由零件組織起來的。OK,回到城堡的例子,前面說的守衛啊,向導啊就是各種各樣的零件。零件需要“類”嗎?直接來看,不需要,它們各成自的職責,管它什么類不類。當你真正需要具有相 同職責的多個零件時,你才真正需要類。我認為就php的執行模式來看,它應該添加一個編程元素:對象,然后賦給它各種修飾,如抽象對象 啦,抽象接口啦,等等。偏偏PHP那班開發人員死腦筋,一味只知道照搬其它語言的概念,對“建設有PHP特色的編程模式”沒有沖勁。 好了,不再瞎扯了:)回到城堡上來。剛進門需要一個人接待你,不管你要什么,你總是要進門的嘛,所以初始檢查就是這個守衛的責任了,放在PHP里,就是所謂的index.php,所有的請求統一由它來接收。這個守衛要做些什么,有哪些職責,都需要你這個設計師來設計。如果這個人不符合進門標準,那么不好意思,只能請你回去了,呵呵。如果通過了檢查,守衛可能要根據你的要求來選擇為你服務的后續人員,比如你只認識英文,那我當然要給你布置英文環境了,呵呵。向導又做什么呢,它要根據你想去的目的地為你指路,所以它需要知道你的目的地,和一張城堡地圖。如果在城堡地圖里找不到你要去的地方,那么sorry,您來錯地方了,地圖是一件公有物品,因為如果有誰要告訴這個衛兵另一個目的地的話,它都必須是在地圖里明確標明的一個地方。對比到PHP里,你很容易就能知道這是一個dispatch+route的過程,呵呵。所以開發這些名詞的那些家伙也只是借了些隱喻而已,沒什么大不了的,只要你想象力豐富,你完全可以顛倒這個一般的城堡規則,按你的意思來構建屬于你的城堡規則。 指令操作數據這種方式,跟數據本身具有綁定的指令這種方式,有什么本質的區別?沒有質的區別。你可能會跟我說在認知上有區別,對,但這種區別我認為并沒有想象中的那么大,只是把主動權倒了一下而已,并沒有多少神奇的能力和效果。面向對象編程實在是被吹得太過了。 不覺得?再看看《領域驅動設計》里的服務。你覺得服務操作實體是不是跟指令操作數據非常相像?這是一個非常大的諷刺,面向對象的終點,卻是它們所不屑的“指令操作數據”的編程方式!嗚呼,“面向對象技術并沒有給我們帶來‘神奇的效應’,不管開發商如何吹噓面向對象OO(Object-Oriented)工具是多么萬能,也不管那些OO狂熱者是多么毅然地前赴后繼,這方面的數據從20世紀80年代以來并沒有發生大的改觀”。 反觀目前的PHP框架,有多少是遵循了軟件設計和對象式編程的精髓呢?很遺憾,沒有。Zend Framework?不客氣地說,它連幼兒都算不上,還只是個嬰兒,而且是個委員會產品,跟軟件藝術相差幾萬光年。 我不喜歡在領域層亂搞對象,這樣你只會給自己帶來麻煩,你很難靈活地把它們保存到數據庫中。雖然我不喜歡過早優化,但即便是不優化,對象映射到關系也是件很麻煩的事情,如果再需要為了性能進行數據庫重構,引入各種不合關系數據原則的修改,則情況會更糟。軟件開發的首要使命就是降低復雜度,對象關系映射卻成功地把復雜度提高到了一個新的高度。當然你熟悉了ORM,小系統開發起來非常快,但不要把這套經驗照搬到大負載系統里來,這樣你會死得很慘。 再看看ROR,它現在已經為了迎合所謂的“企業級應用”而“成功地”變得越來越復雜,等著看它被徹底拋棄吧。 該文章在 2012/4/18 22:11:24 編輯過 |
關鍵字查詢
相關文章
正在查詢... |