扯扯Java開發的淡

  有人說:這個世界上有兩件最難的事, 一是把別人的錢裝進自己的口袋;二是把自己的思想裝進別人的腦袋。對於第一件,有些人做起來並沒有那麼難,而且做得相當成功,那就是乞丐;至於第二件有兩類人做得比較成功,但卻艱辛地多,其中一類是老師,另一類則是創業者。

  我不是老師,也不是創業者,但我想做做第二件事。

  作爲一個從事 Java 後端開發的程序員,自然避免不了要爲前端編寫後臺接口。那麼,應該給前端編寫幾個後端接口呢?這個問題的答案就是我想傳達的思想。

  在回答這個問題之前,我們不妨思考一下另一個問題:要處理這個世界上所有的業務需求,至少需要幾個後端接口?

  我的答案是:一個。

  諸位,先不要拋磚,以免砸到了玉。

  要把這個世界上所有的業務都講清楚,靠這一篇文章自然是不可能。不妨將其濃縮一下:假如此時此刻,我們每個人都是遊戲裏的一個人物,業務場景是控制遊戲裏每個人每天的生活。

  現在我們嘗試用一個接口去處理這個業務,看看是否行得通。

  人的生活無非是喫穿住行,那麼這個接口就需要一個參數去知道一個人是要喫、要穿、要住還是要行。假如這個人是要喫,那麼我們還需要知道這個人要喫什麼,那就需要另外一個參數。同樣地什麼時候喫,喫多少、是否需要付錢、付多少錢等等這些都可以通過增加接口的入參來控制。

  有人會說,除了喫穿住行,人還有其他更多的事可以做,但與此同時這個接口也可以有更多的參數可以加,不是嗎?總之使用一個接口是可以處理控制一個人一天的生活這個業務需求的,進而這一個接口也可以處理這個世界上所有的業務需求,對嗎?

  可以不意味着可行,我們當然不可能使用一個接口去處理所有的業務,因爲這對於前後端的交互是災難性的,其前端傳參和後端參數處理的複雜程度是不人性、也不人道的。

  回到正題:後臺應該爲前端編寫幾個接口?注意這裏的措辭,是“編寫”而非“提供”。

  我的初步答案是:四個,即增刪改查。

  我想做過軟件開發的人聽到的最多的大概就是這四個字了,所謂耳熟能詳,但此時此刻,我想你正在曲解我的意思。因爲我所說的四個並非是四類,而是數量上的 4 個——即對於每個系統來說,後端只需要編寫 4 個接口。

  以上是引言,接下來是我的論證。

  對於任何一個有前後端交互的系統而言,其交互地本質無非是通過前端傳參通知後端應該對哪些數據進行增刪改查操作。比如對於一個電商平臺系統而言,可能會涉及到對商品的增刪改查操作、對店鋪的增刪改查操作、對交易的增刪改查操作等。假如一個電商平臺只有上面列舉出來的三類業務場景,那麼作爲後臺需要爲前端提供的接口數量至少應該是 3 個增刪改查,也就是需要提供 3 * 4 = 12 個接口,注意這裏的措辭,是“提供”而非“編寫”。

  這 12 個接口中有 3 個增 、 3 個刪、 3 個改、3 個查,而所有的增加操作都是類似的,同樣所有的刪改查操作也都是類似的。我們都知道,在 Java 中有類的繼承的概念,倘若我們在父類中實現了增、刪、改、查操作,然後讓子類去繼承,那就意味着所有的增加操作只需要編寫一遍,同樣地,所有的刪改查操作也只需要編寫一遍,也就是說我們只需要在父類中編寫一次增刪改查,對嗎?這樣的話,就印證了我所說的只需要爲前端編寫 4 個接口。

  可是,有一個問題:在父類中實現增刪改查,那麼父類怎麼知道具體應該增刪改查哪一類對象呢?就上面的舉例而言,父類怎麼知道是要對商品進行增刪改查,還是對店鋪進行增刪改查,還是對交易進行增刪改查呢?

  答案是:通過泛型。

  Java 中有泛型的概念,子類在繼承父類的時候可以指明泛型類,通過帶泛型的繼承就可以讓父類知道具體應該操作哪一類對象。說到泛型,我想說一下自己的理解:在 Java 中“一切皆對象”——即一切事物都可以被抽象爲一個對象,而泛型則是對所有抽象的抽象。換言之,泛型是介於抽象的具體對象和 Java 中 Object 對象之間的一種對象形態,因爲它是對具體對象的抽象,也是對抽象對象的具體。

  至此,對於單表的增刪改查操作基本上就解決了。但這還遠不夠,因爲任何一個系統都會涉及到聯表操作,比如在增加操作中可能會有多對多關係的創建、在查詢操作中可能會有多對多關係的數據回顯等。這些問題可以在編寫的這 4 個接口中解決嗎?

  答案是:可以。

  怎麼解決呢?通過註解和反射。我們可以自定義註解,在自定義的註解中去指明一個屬性應該和哪一個類建立關聯關係以及建立的關聯關係是哪一個類,然後通過反射來獲取雙方的主鍵,最後映射至關聯關係表中。在查詢的時候再通過這個註解去解析應該關聯哪個表以進行數據的回顯。我想通篇看下來,大概只有這個地方理解起來有些晦澀,如果你有這種感覺的話,不妨看一下我的另一篇系列博客:基於Java的泛型和反射實現通用的增刪改查,這個系列博客中不僅僅有對於通用的增刪改查的實現,還包含通用的導入、導出、按字段統計等,目前這個系列博客也還在完善之中。

  以上,是對於我“初步的答案”做出的論證。當然“初步的答案”並非正確的答案,因爲前後端的交互可能還會涉及到上傳、下載、導入、導出等,這些操作理論上說也都是可以抽取到父類中的。如此一來,後臺需要爲前端編寫的接口數量就會變爲一個常數,至於這個常數的值則需要看前後端交互有多少種場景。

  以上是我對於 Java 後臺開發的一點感悟,如有失偏頗,還望海涵,若有班門弄斧之嫌,敬請留言指正。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章