面向對象 面向對象是Java程式設計中最核心的思想，基本特征：繼承、封裝、多态。 特征之封裝 将結構、資料、操作封裝在對象實體中，使用時可以不關注對象内部結構，隻能通路開放權限的功能入口，進而降低耦合程度
面向對象是Java程式設計中最核心的思想，基本特征：繼承、封裝、多态。
将結構、資料、操作封裝在對象實體中，使用時可以不關注對象内部結構，隻能通路開放權限的功能入口，進而降低程式耦合程度，提供安全性和可持續維護性。
案例描述Student的學期總結，通過構造方法建構具體的學生對象，并且隻通過conclusion方法擷取學生學期評價。
子類除了提供自身的能力之外，還可以通過繼承的方式擷取父類開放的屬性和方法，以增強自身的功能。
這裡通過isAssignableFrom方法判斷Digital是Phone父類。
不同主體類對同一個動作給出不同的實作方式，多态也是Java描述設計模式的常用手段，最直接的作用就是程式解耦。
通常動物都有發出聲音的能力，但是不同動物聲音不同，這裡基于多态實作，不同動物的聲音特征。
在了解面向對象之後，還需要了解一下基礎的關系模型，在實際的業務中都是基于這些基礎的關系解決場景問題。
繼承關系：強調屬性和方法從父類向子類的傳承。實作關系：強調描述抽象和具體實作的邏輯。
依賴關系：常用來描述方法局部變量或者入參，即類的方法中調用了另一個類。關聯關系：類的成員變量是另一個類，比如常見的一對一，一對多關系。
聚合關系：描述整體與部分的關系，但是部分不需要依賴整體存在。組合關系：描述整體與部分的關系，但是部分需要依賴整體存在。
在面對複雜業務時，可以時常參考設計模式和基本原則，以此設計合理的業務結構，實作代碼的高内聚低耦合，但是在一些特定場景下，也要果斷的突破這些模闆或原則，可以更好的支撐業務。
建立模式
抽象對象執行個體化的建立過程，對不同類型的對象提供高效的管理方式與合理的建立手段。
單例模式
原型模式
工廠模式
建造者模式
結構模式
設計類的組裝模式，合理的對象結構，有利于支援業務的持續疊代，結構會直接影響代碼的可持續維護性。
代理模式
外觀模式
擴充卡模式
裝飾者模式
組合模式
享元模式
橋梁模式
行為模式
行為模式涉及對象職責定義，通信協作，和最具體的業務邏輯實作，明确程式運作時的流程軌迹。
可以基于繼承或實作的方式控制不同類的行為職責，即頂層抽象控制行為，下層逐級做具體邏輯實作；或者直接聚合管理責任對象，做統一配置設定。
觀察者模式
模版方法模式
政策模式
指令模式
調停者模式
備忘錄模式
解釋器模式
疊代器模式
狀态模式
責任鍊模式
通路者模式
開閉原則：在做代碼結構設計時，應該考慮對擴充開放，對修改關閉，抽象思維搭建結構，具體實作擴充細節。
單一職責：一個類應該隻負責一項職責；減少代碼一處變更引起的程式大規模改動情況，降低類的複雜度；
接口隔離：每一個接口應該是一種角色；盡量避免具體實作類中用不到但是又必須實作的方法；
依賴倒轉：上層子產品不應該依賴下層子產品，抽象邏輯不應該依賴具體細節，即中心思想是面向接口程式設計。
裡氏替換：繼承時遵循裡氏替換原則，子類中盡量不要重寫父類的方法，可以擴充父類的功能；
迪米特原則：最少知道原則即類對象對其依賴的類知道的越少越好，以此降低耦合程度；
組合/聚合複用：新對象應使用部分已有的對象，使其成為新對象組成部分，實作已有功能的複用，以此降低單個類的複雜程度。
在業務開發中，很多複雜的邏輯都是基于面向對象的思想做的設計和具體實作，但是在實際上業務是不斷變化的，是以不管是常用的Mvc模式，或者領域設計，隻要經過多個版本疊代，多人參與的開發，到最後代碼在邏輯層面都會讓人着迷。
也就是常說的一種現象：新人重構，老人不斷修複問題，然而鐵打的問題，流水的開發，但凡經曆過重構的同學都知道，所謂的大規模重構很難徹底解決問題，甚至這是個循環動作。是以業務代碼更多是在那個版本周期内是合理的，站在一個開發的角度，這裡也可以了解為筆者個人角度，通常從下面幾個角度去思考具體的業務開發：
規範限制
這是個人認為業務工程中最重要的基礎，不管業務如何複雜，都離不開與之相應的資料增删改查，是以對正常基礎操作做好統一代碼風格管理，這樣有助于别人快速了解整體結構和邏輯。
這裡風格指：接口命名，參數，元件，中間件等統一，以持久層為例，避免多個元件混用的情況，如果是周期相對較長的項目，經常看到單是分頁查詢的實作邏輯都有多種情況。
可複用性
易變是業務本身的特點，是以高度複用的業務代碼本身就存在很大的限制，例如常見的很多方法，為了适配各種場景，不斷擴充入參，然後有些特殊業務也會進行特殊傳參。
還有一些開發常說的，能用一個接口實作，絕對不使用兩個接口，看似很有個性，實際已經走在挖坑的路上，多個功能請求同一個接口，即意味着任何接口的改動都要考慮很多邏輯的适配。
是以從上層向下看，不必過度考慮複用，從下向上看，底層的改動相對較少，應該考慮複用。
業務分層
從項目生命周期的角度思考，業務是一個疊代的過程，不需要過度前衛的設計，項目的生命周期是多久沒人知道，最穩妥的做法是快速疊代，産品和技術工程能快速穩定的支撐業務發展即可。
經典的業務分層管理是快速疊代的基本支撐，例如常用的Mvc模式，在複雜的業務場景下可以再次細化管理，或者向領域設計靠近。
流程分段
業務可以了解為流程管理，小的流程通常service中可以直接處理，但是複雜流程則十分講究設計，一個基礎思想就是分段管理，比較經典的案例就是下單：建構結算頁面時初始化訂單-支付時訂單送出-支付成功才會執行訂單。
細節問題
邏輯上的細節要持續追求嚴謹，業務實作手段和思路适當放寬，流程經得起考驗，底層實作合理的複用，元件選擇上應該站在高緯度，就基本足以。
閱讀标簽
【Java基礎】【設計模式】【結構與算法】【Linux系統】【資料庫】
【分布式架構】【微服務】【大資料元件】【SpringBoot進階】【Spring&Boot基礎】
【資料分析】【技術導圖】【 職場】