【Java-POJO-設計模式】JavaEE中的POJO與設計模式中多態繼承的衝突

最近看《重構》談到利用OO的多態來優化 if else 和 switch 分支語句，可是我發現OO語法中的多態在使用框架的JavaEE中是沒法實踐的。對此，我感到十分的疑惑，加之以前項目中有個「狀態模式」類的模塊被頻繁改動的需求折磨要死，又去看了《設計模式》。《設計模式》中也是強調，使用多態和繼承來實現「狀態」模式。但在採用了 SSH 或 SSM 的項目中，但我歷來沒有在 實體類（POJO/Bean）中見到過「繼承」的語法形式。

 

因而，我搜集了所謂 POJO 、JavaBean、VO、PO、DTO這幾個相近概念的含義。

 

---

 

POJO

 

 一：什麼是POJO
POJO的名稱有多種，pure old java object 、plain ordinary java object 等。
按照Martin Fowler的解釋是「Plain Old Java Object」，從字面上翻譯爲「純潔老式的java對象」，但你們都使用「簡單java對象」來稱呼它。
POJO的內在含義是指那些沒有從任何類繼承、也沒有實現任何接口，更沒有被其它框架侵入的java對象。

 

二：爲何會有POJO？
主要是Java的開發者被EJB的繁雜搞怕了，你們通過反思，又迴歸「純潔老式」的JavaBean，即有無參構造函數，每一個字段都有getter和setter的java類。

 

三：POJO的意義
POJO讓開發者可專一於業務邏輯和脫離框架的單元測試。除此以外， 因爲POJO並不需要繼承框架的類或實現其接口，開發者可以極其靈活地搭建繼承結構和建造應用。
POJO的意義就在於它的簡單而靈活性，由於它的簡單和靈活，使得POJO可以任意擴展，從而勝任多個場合，也就讓一個模型貫穿多個層成爲現實。
先寫一個核心POJO，而後實現業務邏輯接口和持久化接口，就成了Domain Model； UI須要使用時，就實現數據綁定接口，變成VO（View Object）。

 

四：POJO與PO、VO的區別
POJO是指簡單java對象（Plain Old Java Objects、pure old java object 或者 plain ordinary java object）。
PO是指持久對象（persistant object持久對象）。
VO是指值對象或者View對象（Value Object、View Object）。注意，本文的VO特指View Object。
持久對象實際上必須對應數據庫中的entity，因此和POJO有所區別。好比說POJO是由new建立，由GC回收。可是持久對象是insert數據庫建立，由數據庫delete刪除的。基本上持久對象生命週期和數據庫密切相關。另外持久對象每每只能存在一個數據庫Connection之中，Connnection關閉之後，持久對象就不存在了，而POJO只要不被GC回收，老是存在的。
因爲存在諸多差異，所以持久對象PO(Persistent Object)在代碼上確定和POJO不一樣，起碼PO相對於POJO會增長一些用來管理數據庫entity狀態的屬性和方法。而ORM追求的目標就是要PO在使用上儘可能和POJO一致，對於程序員來講，他們能夠把PO當作POJO來用，而感受不到PO的存在。

 

五：POJO的擴展
POJO僅包含最簡單的字段屬性，沒有多餘的東西，它本質上就是一個普通的JavaBean。
可是在POJO的基礎上，可以擴展出不一樣的對象。
爲POJO增長了持久化的方法（Insert、Update、Delete……）以後，POJO就變成了PO。
爲POJO增長了數據綁定功能以後，POJO就變成了View Object，即UI Model。
爲POJO增長業務邏輯的方法（好比單據審覈、轉賬……）以後，POJO就變成了Domain Model。
POJO還能夠看成DTO使用。

 

---

 

 

我一直認爲：概念，名詞，理論無非是人用來理解、抽象事物的，是拿來用的。若是沒有相應的名詞，咱們本身也能夠創造。

 

我的感受，在SSM或SSH的 JavaWeb 項目中，領域模型【Domain Model】（如成績管理系統裏面的學生、成績等實體） 通常是被簡化爲 POJO ，而後這個 POJO 既用做 VO 也用做 PO 。Struts 或 Sprint MVC 用 VO 來包裹頁面的數據，傳給 Action  或 Controller ； Action  或 Controller 內部 用 DTO【Data Transfer Object 】互相傳輸數據； Hibernate 或者 MyBatis 用 PO 來包裹 業務邏輯處理過的數據 放到 數據庫中。在這裏，VO 和 PO 由於簡單，就使用同一個 POJO 了事。可是若是咱們遇到複雜的 領域模型，這個須要使用 繼承和多態的 結構應該放在哪裏呢 ？  POJO ？ PO？VO？DTO？我以爲，這時候，是否是就應該須要另一層 ？

 

舉個在《設計模式：Java語言》中的「狀態模式」的例子。

有個傳送帶，它有一個用於放入物品的門和控制門開關的按鈕。當門關着時，按鈕開門；當門開着時，按鈕使門繼續保持打開；當門開着，且2分鐘沒有操做時，門自動關閉；當門正在關閉時，按鈕使門打開；當門正在打開時，按鈕開門。【具體細節忘了。。。】

博主：簡單的說，就是按鈕老是要開門，門超時會自動關閉。門除了開關兩個狀態，還有「正在開 Opening 」  和 「正在關 Closing」兩個狀態。

書中建議使用 狀態模式，也就是說須要 設計 含有繼承關係的幾個類。若是這個功能出如今採用了 SSM 框架的 JavaEE項目中，那麼，這個繼承關係該設計到哪裏呢？