為什么PHP+Java的開發(fā)中不要太面向對象

為什么PHP+Java的開發(fā)中不要太面向對象，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

說起面向對象，現(xiàn)在很多語言多少都有一些。Java是傳統(tǒng)的面向對象語言，PHP也有一些面向對象，但不是很好。完全的面向對象在具體的項目中（本文是Web開發(fā)項目），有時候其實并不是***的選擇。本文作者最終選擇了PHP+Java的一個模式，并分享了一些自己的經(jīng)驗。

我較早接觸了C++（高中），也較早接受了面向對象思想。面向對象思想更接近人的思考方式，其封裝、繼承等特性也常常能夠簡化一些工作，最重要的是思路看起來清晰多了。我對面向對象的思想深信不疑，直到有一天，我在WEB項目中陷入困惑。

我以前的工作也都是WEB開發(fā)相關的，通常項目里都是接口、實現(xiàn)，service層，DAO層這個樣子。久而久之，就習慣了這種模式。后來，我開始自己做網(wǎng)站（自己運營），也沿用這種模式，花了一陣子時間把東西弄出來，可以跑了，問題也隨之而來了。大家都知道，類似門戶網(wǎng)站這樣的東西，尤其是成長期的網(wǎng)站，可能會經(jīng)常面對一些變更、擴展。它不像企業(yè)項目或是以穩(wěn)定模式運營的網(wǎng)站，可以一套寫好的程序一直用下去?？墒荍AVA的東西改動起來有點麻煩。

***：項目里用了很多接口，業(yè)務變更有不少時候還要動接口。也許有人會說，這是因為需求沒做好。是的，可以這么認為，但有個前提：需求根本沒法一步到位，否則網(wǎng)站也別跑了，等需求分析做好，花都謝了。回憶一下這個經(jīng)典的流程：要增加一個特性（頁面部分暫不討論），先增加或修改一個service接口；然后增加或修改其實現(xiàn)；接著視需要可能還要再增加或修改一個DAO層接口，對應的要增加或修改其實現(xiàn)；***，我們真正要改的，往往只是一個SQL語句。

這一系列流程太過繁瑣了。門戶網(wǎng)站基本是展示信息的，它的業(yè)務邏輯，說到底基本上是SQL語句體現(xiàn)出來的。你想想看，網(wǎng)站上顯示什么東西，怎么排序，怎么聚合，這些不都對應著相應的SQL語句么？如果你非要把DAO層寫成基本的增刪改，然后在service層大作文章去實現(xiàn)本來對應著一個SQL語句的業(yè)務羅輯，這有什么意思呢？純粹為了分層而分層？為了面向對象而面向對象？更不用說那一堆接口，平白增加工作量。我當然不會否認接口在編程思想中的意義，只是傳統(tǒng)的JAVA WEB編程中的那一堆接口，是否真正是一個合理應用呢？我看很多情況下不是。我后來用PHP重寫我的項目中的一大部分功能，只用了幾天的時間，沒有分層，沒有接口。這樣帶來的工作效率的提升，真是愜意！

第二：JAVA WEB項目的發(fā)布通常需要重啟服務，造成WEB運行中斷。不少人在討論熱部署，我不知道熱部暑最終能達到怎樣一個水平，但我想信無法達到像PHP那樣隨時修改文件隨時生效。為了不中斷服務，我通常選擇做個集群，輪流發(fā)布。這樣雖然仍舊有可能產生一些問題，但比中斷應用好多了?？墒羌簳戆l(fā)布上的麻煩，集群本身也未必是我真正需要的。

隨之而來的還有一些小問題，比如如果我項目中包含一些存儲大量文件的文件夾，在發(fā)布的時候又要特別處理，這樣很不爽。即使做軟鏈接，發(fā)布時也免不了要做額外工作。這些問題，當然我想信會有更好的解決辦法，我個人目前仍在探索中。

面對上述這些問題，我最終不再堅守面向對象。我把項目改成了前PHP后JAVA的形式。PHP做前端顯得靈活多了，整個改版，PHP的邏輯部分沒花多少時間，時間都用在了頁面設計上；JAVA的后端又能保證穩(wěn)定高效，易于安全設計。由此，我最終發(fā)出了“不要太面象對象”這一感嘆。需求決定一切，跟著別人的思想走，跟入邪教沒區(qū)別。

問題也還并沒有結束，對JAVA后端部分，我還在探索一個基于插件式的可以熱加載、缷截插件的CMS后端系統(tǒng)。呵，不能因為上面的原因把面象對象一棒子打死。

不過不管怎樣，看了作者的描述，倒是不妨試試PHP+Java的組合：看看放棄一些面向對象能夠帶來些什么好處吧。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業(yè)資訊頻道，感謝您對億速云的支持。