漫淡面向對象——POJO對象

產品或者服務由數據存儲和數據計算組成。pojo對象就是用於數據存儲。一旦肯定後，整個應用或者產品的數據來源就肯定。好比一個頁面或者功能須要使用什麼數據就能夠快速找到對應的對象或者經過對象的關係找出來。

pojo對象屬於對系統的靜態描述。它應該是名詞，不該該是動詞或者其餘。動詞、類型或者狀態等應該是算法類型的對象，權限應該是AOP考慮的，在後面的漫談裏還會詳細提到。

目的

對領域的客觀描述反應。好比說：教育領域，農業領域，電商領域，零食領域等。這些只要領域背景沒有變化，就會是客觀穩定的。固然不一樣的產品的商業模式對同一個領域的理解也會不一樣，這些是會常常變化的，可是一般也只是體如今流程、類型、算法、功能等上面，這些並不影響pojo對象。

• 全部人在溝通的時候理解一致
• 每一個對象職責單1、明確、不可替代

屬性分類

爲了快速區分屬性，而且快速找到真正的pojo對象和屬性。這些屬性能夠在產品裏的新增、詳情、列表等功能裏獲得體現。

自描述

通常體現出來的就是手動輸入。好比：名稱，標題等。

關聯

有依賴來源，即在別的地方是手動輸入，可是當前功能是選擇。好比：選擇地區，選擇類型。

冗餘

方便查詢，減小複雜度。通常有如下狀況：

• 一旦生成不會變化的，能夠考慮冗餘，由於這樣能夠減小複雜度。
• 偏統計類。好比：視頻裏冗餘評論數購買數。
• 爲了減小不一樣類型表的依賴。

功能

個性化業務，純粹是爲了作功能

只留自描述，這個很難。須要深層次瞭解領域。經過領域驅動設計。這樣能夠經過面向對象，經過不多的關注點，對整個系統有個靜態的認識。並且還能夠判斷出產品變動的時候對整個系統的結構（即數據存儲）有什麼影響。特別是出現新名詞的時候。

須要根據產品的實際狀況來判斷這些屬性怎麼規劃。若是是想要快速、簡單，可是4種類型都放到pojo上，開發是最快的，可是同時確定也是擴展性最差的。也須要根據產品的真實需求來判斷怎麼處理後面3種類型的屬性。

抽取步驟

不少童鞋打着面向對象的幌子幹着面向過程的事。在抽取名詞的時候同時又考慮算法、流程、權限等。這樣一來關注點幾何倍數增加，原本應該用於考慮pojo對象是否合理的時間更沒辦法充分獲得利用。

不少童鞋想成一次就把對象抽取出來。實現上抽取比印象中還要複雜。因此建議的是分步驟，循序漸進的去抽取才是最快的辦法。

枚舉

只是把產品裏涉及到的全部名詞枚舉出來。
下面是枚舉時的陷阱：

• 不要去經過本身的理解去修更名詞叫法
• 不要去忽略本身以爲不重要的名詞
• 不要考慮表怎麼存儲
• 不要考慮非名詞

這些陷阱很容易讓後期返工。

刪除

刪除和產品（領域）無關的名詞。好比：文案可能出現了故宮或者平臺名等和本領域無關的名詞。

去重

必需確保每一個名詞都是職責單一，不可替代的。
通常去重的特徵以下：不一樣的名詞體現出來的屬性，功能和生命週期是同樣的，只是描述不一樣。
好比： 不一樣角色的人在對同一個名詞描述不一樣，他們在新增的時候屬性類似度很是高，流程也特別像。

通常的反問本身或者產品：

• 它們的不一樣點在哪？
• 若是改一個地方，另外一個地方會不會須要同時修改？
• 若是把它們作成同樣會有什麼問題嗎？

添加

• 在描述一個概念的時候，必須經過很是多其餘對象，並且常常提。
• 雖然產品沒有提過，可是在實施的時候發生有不少對象有同樣的特性。常見狀況：
  • 一個列表涉及到很是多的名詞，可是列表自己產品並無體現概念。
  • 不一樣的名詞，他們的屬性很雷同，並且生命週期幾乎是同樣的，有種幾條平行線的感受。好比說：一樣要新增、發佈、審覈等

聚合

把屬性名詞聚合到對象名詞裏。這裏務必確認只放自描述屬性。其餘的屬性暫時不考慮，由於能夠很方便的經過關係來描述，並且這個也常常會變化。

陷阱

若是有如下的狀況說明對象分析的不夠合理，後面很容易返工，請務必重視。

單方面描述

有一方有一直在說，可是另外一方歷來不提。說明這裏缺乏重要名詞。

描述不一致

在描述同一名詞的時候，每每需求進一步翻譯。
這樣可能會出現的問題是：

• 溝通和維護成本增長
• 極可能缺乏重要信息或者說關係理解的不對等。

組合描述

• 用多個詞來描述一個概念。須要一個新詞。
• 一個概念沒有具體自描述，而是關係出來的，可是又是溝通描述時常常出現。

推薦書單

• 《UML基礎，應用與案例》
• 《領域驅動設計》