設計模式之 OOA，OOD，OOP，OOPL

什麼是面向對象編程和麪向對象編程語言？

面向對象編程的英文縮寫是 OOP，全稱是 Object Oriented Programming。對應地，面向對象編程語言的英文縮寫是 OOPL，全稱是 Object Oriented Programming Language。

面向對象編程中有兩個很是重要、很是基礎的概念，那就是類（class）和對象（object）。若是不按照嚴格的定義來講，大部分編程語言都是面向對象編程語言，好比 Java、C++、Go、Python、C#、Ruby、JavaScript、Objective-C、Scala、PHP、Perl 等等。除此以外，大部分程序員在開發項目的時候，都是基於面向對象編程語言進行的面向對象編程

• 面向對象編程是一種編程範式或編程風格。它以類或對象做爲組織代碼的基本單元，並將封裝、抽象、繼承、多態四個特性，做爲代碼設計和實現的基石 。
• 面向對象編程語言是支持類或對象的語法機制，並有現成的語法機制，能方便地實現面向對象編程四大特性（封裝、抽象、繼承、多態）的編程語言。

通常來說， 面向對象編程都是經過使用面向對象編程語言來進行的，可是，不用面向對象編程語言，咱們照樣能夠進行面向對象編程。反過來說，即使咱們使用面向對象編程語言，寫出來的代碼也不必定是面向對象編程風格的，也有多是面向過程編程風格的。

理解面向對象編程及面向對象編程語言兩個概念，其中最關鍵的一點就是理解面向對象編程的四大特性。這四大特性分別是：封裝、抽象、繼承、多態。

如何斷定某編程語言是不是面向對象編程語言？

若是按照剛剛咱們給出的嚴格的面向對象編程語言的定義，前面提到的有些編程語言，並非嚴格意義上的面向對象編程語言，好比 JavaScript，它不支持封裝和繼承特性。

實際上，面向對象編程從字面上，按照最簡單、最原始的方式來理解，就是將對象或類做爲代碼組織的基本單元，來進行編程的一種編程範式或者編程風格，並不必定須要封裝、抽象、繼承、多態這四大特性的支持。可是，在進行面向對象編程的過程當中，人們不停地總結髮現，有了這四大特性，咱們就能更容易地實現各類面向對象的代碼設計思路。

好比，咱們在面向對象編程的過程當中，常常會遇到 is-a 這種類關係（好比狗是一種動物），而繼承這個特性就能很好地支持這種 is-a 的代碼設計思路，而且解決代碼複用的問題，因此，繼承就成了面向對象編程的四大特性之一。可是隨着編程語言的不斷迭代、演化，人們發現繼承這種特性容易形成層次不清、代碼混亂，因此，不少編程語言在設計的時候就開始摒棄繼承特性，好比 Go 語言。可是，咱們並不能由於它摒棄了繼承特性，就一刀切地認爲它不是面向對象編程語言了。

實際上，只要某種編程語言支持類或對象的語法概念，而且以此做爲組織代碼的基本單元，那就能夠被粗略地認爲它就是面向對象編程語言了。

至因而否有現成的語法機制，徹底地支持了面向對象編程的四大特性、是否對四大特性有所取捨和優化，能夠不做爲斷定的標準。基於此，咱們纔有了前面的說法，按照嚴格的定義，不少語言都不能算得上面向對象編程語言，但按照不嚴格的定義來說，如今流行的大部分編程語言都是面向對象編程語言。

什麼是面向對象分析和麪向對象設計？

實際上，跟面向對象編程常常放到一起來說的還有另外兩個概念，那就是面向對象分析（OOA）和面向對象設計（OOD）。
面向對象分析英文縮寫是 OOA，全稱是 Object Oriented Analysis；
面向對象設計的英文縮寫是 OOD，全稱是 Object Oriented Design。
OOA、OOD、OOP 三個連在一塊兒就是面向對象分析、設計、編程（實現），正好是面向對象軟件開發要經歷的三個階段。

之因此在前面加 「面向對象」 這幾個字，是由於咱們是圍繞着對象或類來作需求分析和設計的。
分析和設計兩個階段最終的產出是類的設計，包括程序被拆解爲哪些類，每一個類有哪些屬性方法，類與類之間如何交互等等。它們比其餘的分析和設計更加具體、更加落地、更加貼近編碼，更可以順利地過渡到面向對象編程環節。這也是面向對象分析和設計，與其餘分析和設計最大的不一樣點。

那面向對象分析、設計、編程到底都負責作哪些工做呢？

簡單點講，面向對象分析就是要搞清楚作什麼，面向對象設計就是要搞清楚怎麼作，面向對象編程就是將分析和設計的的結果翻譯成代碼的過程。

什麼是 UML？咱們是否須要 UML？

提到面向對象分析、設計、編程，咱們就不得不提到另一個概念，那就是 UML（Unified Model Language），統一建模語言。
不少講解面向對象或設計模式的書籍，經常使用它來畫圖表達面向對象或設計模式的設計思路
經常使用的有 7 種：類圖、序列圖、組件圖、部署圖、用例圖、狀態圖和活動圖。

類圖

類圖是最多見的 UML 圖形，用來描述類的特性和類之間的靜態關係。
一個類包含三個部分：類的名字、類的屬性列表和類的方法列表。
類之間有 6 種靜態關係：關聯、依賴、組合、聚合、繼承、泛化。把相關的一組類及其關係用一張圖畫出來，就是類圖。
類圖主要是在詳細設計階段畫，開發工程師只須要按照類圖實現代碼就能夠了，只要類方法的邏輯不是太複雜，不一樣的工程師實現出來的代碼幾乎是同樣的，這樣能夠保證軟件的規範、統一。

在實踐中，咱們一般不須要把一個軟件全部的類都畫出來，把核心的、有表明性的、有必定技術難度的類圖畫出來，通常就能夠了

具體推薦的學習連接：http://www.uml.org.cn/oobject/201610282.asp

序列圖

序列圖則用來描述參與者之間的動態調用關係。每一個參與者有一條垂直向下的生命線，這條線用虛線表示，而參與者之間的消息也從上到下表示其調用的先後順序關係，這正是序列圖這個詞的由來。每一個生命線都有一個激活條，只有在參與者活動的時候纔是激活的。

序列圖一般用於表示對象之間的交互，這個對象能夠是類對象，也能夠是更大粒度的參與者，好比組件、服務器、子系統等，總之，只要是描述不一樣參與者之間交互的，均可以使用序列圖，也就是說，在軟件設計的不一樣階段，均可以畫序列圖。

組件圖

組件是比類粒度更大的設計元素，一個組件中一般包含不少個類。組件圖有的時候和包圖的用途比較接近，組件圖一般用來描述物理上的組件，好比一個 JAR，一個 DLL 等等。在實踐中，咱們進行模塊設計的時候更多的是用組件圖。

組件圖描述組件之間的靜態關係，主要是依賴關係，由於組件的粒度比較粗，一般用以描述和設計軟件的模塊及其之間的關係，須要在設計早期階段就畫出來，所以組件圖通常用在概要設計階段。

部署圖

部署圖描述軟件系統的最終部署狀況，好比須要部署多少服務器，關鍵組件都部署在哪些服務器上。
部署圖是軟件系統最終物理呈現的藍圖，根據部署圖，全部相關者，諸如客戶、老闆、工程師都能清晰地瞭解到最終運行的系統在物理上是什麼樣子，和現有的系統服務器的關係，和第三方服務器的關係。根據部署圖，還能夠估算服務器和第三方軟件的採購成本。

部署圖是整個軟件設計模型中，比較宏觀的一種圖，是在設計早期就須要畫的一種模型圖。根據部署圖，各方能夠討論對這個方案是否定可。只有對部署圖達成共識，才能繼續後面的細節設計。部署圖主要用在概要設計階段。

用例圖

用例圖主要用在需求分析階段，經過反映用戶和軟件系統的交互，描述系統的功能需求

圖中小人形象的元素，被稱爲角色，角色能夠是人，也能夠是其餘的系統。
系統的功能被一個矩形框框起來，這個矩形框被稱爲用例的邊界。框裏的橢圓表示一個一個的功能，功能之間能夠調用依賴，也能夠進行功能擴展。由於用例圖中功能描述比較簡單，一般還須要對用例圖配以文字說明，造成需求文檔。

狀態圖

狀態圖用來展現單個對象生命週期的狀態變遷。

業務系統中，不少重要的領域對象都有比較複雜的狀態變遷，好比帳號，有建立狀態、激活狀態、凍結狀態、欠費狀態等等各類狀態。

這些狀態的變遷描述能夠在用例圖中用文字描述，一張狀態圖描述一個對象生命週期的各類狀態，及其變遷的關係。狀態與變遷關係用一張狀態圖就能夠搞定。

活動圖

活動圖主要用來描述過程邏輯和業務流程。UML 中沒有流程圖，不少時候，人們用活動圖代替流程圖。

活動圖和早期流程圖的圖形元素也很接近，實心圓表明流程開始，空心圓表明流程結束，圓角矩形表示活動，菱形表示分支判斷。此外，活動圖引入了一個重要的概念——泳道。活動圖能夠根據活動的範圍，將活動根據領域、系統和角色等劃分到不一樣的泳道中，使流程邊界更加清晰。活動圖也比較有普適性，能夠在需求分析階段描述業務流程，也能夠在概要設計階段描述子系統和組件的交互，還能夠在詳細設計階段描述一個類方法內部的計算流程。

因爲狀態圖和活動圖設計和表達有相似的地方，有時合在一塊兒表達在一張圖上

推薦畫圖工具：https://www.processon.com/ ：能夠邀請夥伴一塊兒繪圖，支持導出導入

舒適提示：要想徹底掌握，而且熟練運用UML 圖，確定要花不少的學習精力，本質是讓團隊更清晰地理解設計