面向對象分析與設計是指根據面向對象方法學對軟件系統進行分析與設計。在面向對象分析與設計的定義中有三個關鍵詞：面向對象、分析、設計。所以，為了更好地理解面向對象分析與設計的作用，我們首先要理解什麼是面向對象，以及面向對象分析和面向對象設計的原則。

什麼是面向對象

面向對象是對現實世界進行理解和抽象的方法，是計算機編程技術發展到一定階段後産生的一種軟件開發方法，具有抽象、封裝、繼承、多态等特征，還形成設計原則和設計模式的智慧結晶。我們可以使用一張圖來更為形象地展現面向對象所涉及内容之間的關系，如圖3.21所示。

圖3.21

面向對象的特征

面向對象的特征如下。

（1）封裝：指将相關屬性和方法重組成一個新的對象，并提供對外訪問的接口，對數據的訪問或修改隻能通過該接口進行。電商商品有拍下和支付等行為特征，但其實現細節對用戶來說是不可見的，所以在進行商品購買的過程中，用戶并不清楚交易是如何進行的，以及訂單的狀态是如何發生改變的，這就體現了對象的封裝性。

（2）繼承：指某類對象可以繼承其他類對象的屬性和方法，是一種類之間的層次關系表達。繼承有單繼承與多繼承兩種方式：單繼承指子類隻有一個父類；多繼承指子類有一個以上的父類。繼承是代碼重用的具體表現之一，也破壞了對象的封裝性，父類的公共屬性和方法對子類開放，如果修改父類的公共屬性和方法，就會導緻所有子類的改變，這在一定程度上其實破壞了系統的可擴展性。

（3）多态：指不同的類對象對同一消息做出響應，但同一消息可以根據發送的不同對象進行不同的處理，最終得到不同的執行結果。

接口的不同實現方式也被稱為多态。

（4）抽象：指為了達到某種目的，對涉及的信息和現象進行過濾，将共性元素進行合并，這些元素同時具有獨立性和特殊性。抽象也是面向對象分析與設計的基礎。

面向對象設計的原則

為了設計出一個好的軟件系統，就必須遵照一定的規則，而衡量軟件設計質量的首要标準就是該設計能否滿足軟件的功能需求。除了功能需求，還有很多衡量軟件設計質量的标準，主要包括高内聚、低耦合、可擴展和可複用。

（1）高内聚：系統中的模塊具有高度相關的職責，如果除了這些職責内的任務，沒有過多的其他任務，該模塊就具有高内聚性，反之具有低内聚性。并且系統中的模塊與模塊之間有較高的協作性，也就是常說的單一責任原則。

（2）低耦合：耦合指元素與元素之間連接、感知和依賴的程度。這裡所說的元素，可以指功能、對象（類），也可以指系統、子系統、模塊。耦合度越低，系統越獨立，可擴展性就會越好，所以在設計系統時首先要考慮對元素的劃分。

（3）可擴展：用于應對更大規模的業務及軟件的成長，通常采用動态加載的插件、回調函數、抽象接口及認真設計的代碼結構和類層次結構，使系統在面對不斷變化的需求時，其代碼不被大量重構開發，比如添加新功能或修改完善現有功能。

（4）可複用：又叫作重用，即重複使用，可以利用已有的代碼或者相關模塊去實現新的功能需求，實現高效、低成本和高質量。

面向對象是一種解決現實問題的思想，讓我們把重點放在現實的客體上。我們可以通過 UML弄清楚這些客體之間的關系，最後把客體與客體之間的關系用面向對象的語言表達出來。客體與客體之間的關系如圖3.22所示。

圖3.22

回顧前面介紹的将大象放入冰箱的例子，我們如何使用面向對象思想實現這個例子呢？首先，找出現實世界中的動作和實體：①打開冰箱；②将大象放入冰箱；③關閉冰箱。然後，抽象出概念：①冰箱、可以打開門、可以存儲、可以關門；②大象、體重、體積。最後，用計算機中的類來實現該邏輯關系，這樣就有了elephant和fridge兩個類。

面向對象的代碼實現如下：

雖然面向對象起初專指在程序設計中采用封裝、繼承、多态、抽象等設計方法，然而現在它已經滲透到軟件開發的各個方面，比如面向對象的分析（OOA）、面向對象的設計（OOD）和面向對象的編程（OOP）等環節，其在各環節的職責如下。

（1）在需求分析階段采用面向對象的分析方法，這個階段不需要思考怎麼用程序實現它，隻需要思考和分析需求中穩定不變的客體是什麼，這些客體之間的關系又是什麼，以及完成概要建模。

（2）在設計階段采用面向對象的設計方法，把在需求分析階段分析出來的需求進一步擴充為模型，變成可實現的、符合成本的、模塊化的、低耦合高内聚的模型。

（3）在編程開發階段采用面向對象的編程語言來具體實現在前一個階段得到的業務模型。

面向服務（SOA）是一種架構思想，可以是跨語言的，也可以是跨平台的，其宗旨就是根據項目的服務完成架構搭建，以服務為基準點完成系統的組件化和模塊化。比如，在電商系統中提供商品搜索服務、商品查詢服務、用戶信息服務、訂單查詢服務，等等，這些都是由電商系統提供的服務，這些服務由一個個的業務點組成，一個服務就是一條業務線，整個項目的服務體系可以說是由各種各樣的業務點組成的，并由業務線串聯而成，而服務的實現過程就是面向服務分析與設計。

Web Service模式

在Web Service模式下，服務提供者創建服務，并決定将其公開并發布。發布是通過将服務信息發布到服務目錄上來完成的。另外，服務消費者将在服務目錄中搜索滿足必要條件的服務，在找到服務後，通過服務目錄中的可用服務信息，就能夠以正确的方式直接調用服務提供者，從而滿足業務的需求。其過程如圖3.23所示。

圖3.23

對Web Service中的一些術語解釋說明如下。

◎ 服務提供者：指服用的被調用方，即為其他服務提供服務的服務。

◎ 服務消費者：指服務的調用方，即依賴其他服務的服務。

◎ 服務目錄：用于向消費者提供可以用的服務目錄。

◎ SOAP（Simple Object Access Protocol，簡單對象訪問協議）：是交換數據的一種協議規範，是一種輕量的、簡單的、基于XML 的協議，它被設計成在 Web 上交換結構化的和固定化的信息。

◎ WSDL（Web Service Description Language，Web服務描述語言）：用來描述Web服務發布的XML格式。

◎ UDDI （ Universal Description Discovery andIntegration）：指通用的描述、發現、集成服務，用來存儲服務信息的目錄及描述服務界面的目錄。我們可以通過 UDDI根據自己的需要動态查找并使用We b服務，也可以将自己的We b服務動态發布到UDDI注冊中心，供其他用戶使用。

ESB模式

ESB（Enterprise Service Bus，企業服務總線）提供服務對接、協議轉換、消息傳輸、數據轉換、内容路由等功能，隐藏了服務提供者的物理位置、協議和數據格式，由中間件産品技術實現，通過事件驅動和XML消息引擎為更複雜的面向服務的架構提供服務。ESB通常在企業的消息系統上提供一個抽象層，可以幫助設計者利用消息（不用編碼）就能完成集成工作，其架構如圖3.24所示。

圖3.24

微服務架構

微服務架構是SOA架構的延續，是一種比較現代化的細粒度的SOA實現方式，強調業務需要徹底組件化和服務化，也就是說，系統需要按照業務邊界做細粒度的拆分和部署。這樣，原有的單個業務系統會被拆分為多個可以獨立開發、設計和運行的微服務系統，這些微服務之間通過REST（Representational State Transfer）完成交互和集成。

那麼，微服務架構又具有什麼樣的特點呢？可簡單歸納為如下三點。

（1）獨立部署、靈活擴展。傳統的單體架構是以整個系統為單位進行部署的，而微服務架構是以每一個獨立組件為單位進行部署的，可以根據每個服務的高并發要求的不同進行不同的部署。比如，服務A需要部署10台機器，服務B需要部署20台機器，而服務C隻需要部署3台機器，像這種靈活的部署方案隻有微服務架構才能實現，近幾年流行的容器化更為微服務架構提供了高效、靈活的部署方案。

（2）資源的有效隔離。微服務設計的原則之一，就是每一個微服務都擁有獨立的數據源，假如微服務 A想要讀寫微服務 B的數據庫，則隻能調用微服務 B對外暴露的接口來完成，這樣就有效避免了服務之間争用數據庫和緩存資源所帶來的問題。另外，由于每一個微服務實例都運行在不同的容器中，所以更好地實現了服務器資源（比如内存、CPU等）的隔離，如圖3.25所示。

圖3.25

（3）敏捷的組織結構。微服務設計的思想也改變了原有的企業研發團隊的組織架構，從以往水平的職能型團隊變成了垂直的業務型團隊。職能型團隊和業務型團隊的架構如圖 3.26和圖3.27所示。

圖3.26

圖3.27

當然，微服務架構也帶來了各種各樣的問題，如下所述。

◎ 微服務架構把原有的項目拆成多個獨立的工程，增加了開發、測試和運維的複雜度。◎ 微服務架構需要保證不同服務之間的數據一緻性，引入了分布式事物和最終一緻性機制，為設計和開發帶來了挑戰。

◎ 很多微服務的拆分粒度過大，導緻服務的調用鍊過長，性能降低，維護成本增加。

領域驅動設計可以彌補微服務架構中的很多不足，為微服務架構提供指導思想，比如服務拆分的粒度和事務合理設計等，下面重點介紹領域驅動設計的詳細方法。

1. 下篇文章給大家講解的是程序員技術精進： 領域驅動設計， 領域模型實踐；
2. 覺得文章不錯的朋友可以轉發此文關注小編；
3. 感謝大家的支持！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!