PHP+Java的開發經驗：不要太面向對象
說起面向對象，現在很多語言多少都有一些。Java是傳統的面向對象語言，PHP也有一些面向對象，但不是很好。完全的面向對象在具體的項目中（本文是Web開發項目），有時候其實并不是***的選擇。本文作者最終選擇了PHP+Java的一個模式，并分享了一些自己的經驗。
我較早接觸了C++（高中），也較早接受了面向對象思想。面向對象思想更接近人的思考方式，其封裝、繼承等特性也常常能夠簡化一些工作，最重要的是思路看起來清晰多了。我對面向對象的思想深信不疑，直到有一天，我在WEB項目中陷入困惑。
我以前的工作也都是WEB開發相關的，通常項目里都是接口、實現，service層，DAO層這個樣子。久而久之，就習慣了這種模式。后來，我開始自己做網站（自己運營），也沿用這種模式，花了一陣子時間把東西弄出來，可以跑了，問題也隨之而來了。大家都知道，類似門戶網站這樣的東西，尤其是成長期的網站，可能會經常面對一些變更、擴展。它不像企業項目或是以穩定模式運營的網站，可以一套寫好的程序一直用下去。可是JAVA的東西改動起來有點麻煩。
***：項目里用了很多接口，業務變更有不少時候還要動接口。也許有人會說，這是因為需求沒做好。是的，可以這么認為，但有個前提：需求根本沒法一步到位，否則網站也別跑了，等需求分析做好，花都謝了。回憶一下這個經典的流程：要增加一個特性（頁面部分暫不討論），先增加或修改一個service接口；然后增加或修改其實現；接著視需要可能還要再增加或修改一個DAO層接口，對應的要增加或修改其實現；***，我們真正要改的，往往只是一個SQL語句。
這一系列流程太過繁瑣了。門戶網站基本是展示信息的，它的業務邏輯，說到底基本上是SQL語句體現出來的。你想想看，網站上顯示什么東西，怎么排序，怎么聚合，這些不都對應著相應的SQL語句么？如果你非要把DAO層寫成基本的增刪改，然后在service層大作文章去實現本來對應著一個SQL語句的業務羅輯，這有什么意思呢？純粹為了分層而分層？為了面向對象而面向對象？更不用說那一堆接口，平白增加工作量。我當然不會否認接口在編程思想中的意義，只是傳統的JAVA WEB編程中的那一堆接口，是否真正是一個合理應用呢？我看很多情況下不是。我后來用PHP重寫我的項目中的一大部分功能，只用了幾天的時間，沒有分層，沒有接口。這樣帶來的工作效率的提升，真是愜意！
第二：JAVA WEB項目的發布通常需要重啟服務，造成WEB運行中斷。不少人在討論熱部署，我不知道熱部暑最終能達到怎樣一個水平，但我想信無法達到像PHP那樣隨時修改文件隨時生效。為了不中斷服務，我通常選擇做個集群，輪流發布。這樣雖然仍舊有可能產生一些問題，但比中斷應用好多了。可是集群會帶來發布上的麻煩，集群本身也未必是我真正需要的。
隨之而來的還有一些小問題，比如如果我項目中包含一些存儲大量文件的文件夾，在發布的時候又要特別處理，這樣很不爽。即使做軟鏈接，發布時也免不了要做額外工作。這些問題，當然我想信會有更好的解決辦法，我個人目前仍在探索中。
面對上述這些問題，我最終不再堅守面向對象。我把項目改成了前PHP后JAVA的形式。PHP做前端顯得靈活多了，整個改版，PHP的邏輯部分沒花多少時間，時間都用在了頁面設計上；JAVA的后端又能保證穩定高效，易于安全設計。由此，我最終發出了“不要太面象對象”這一感嘆。需求決定一切，跟著別人的思想走，跟入邪教沒區別。
問題也還并沒有結束，對JAVA后端部分，我還在探索一個基于插件式的可以熱加載、缷截插件的CMS后端系統。呵，不能因為上面的原因把面象對象一棒子打死。
不過不管怎樣，看了作者的描述，倒是不妨試試PHP+Java的組合：看看放棄一些面向對象能夠帶來些什么好處吧。
【編輯推薦】
