注：本文是針對軟體設計師資格考試中重要考點編寫的，不可避免地會造成知識點淩亂。
軟體設計師——面向對象方法（包含設計模式）
- 多态
- 類與類之間的關系
- 用例與用例之間的關系
- 面向對象的七大原則
- UML基礎
-
- UML中的4種事物
- UML中的14中圖
-
- (1)類圖(Class Diagram)
- (3)構件圖(Component Diagram)
- (4)組合結構圖Composite Structure Diagram)
- (5)用例圖(Use Case Diagram)
- (6)順序圖(Sequence Diagram序列圖)
- (7)通信圖（Communication Diagram）
- (8)定時圖(Timing Diagram,計時圖)
- (9)狀态圖( State Diagram)。
- (10)活動圖(Activity Diagram)
- (11)部署圖(Deployment Diagram)
- (12)制品圖(Artifact Diagram)
- (13)包圖(Package Diagram)
- (14)互動概覽圖(Interaction Overview Diagram)
- 設計模式
-
- Adapter（擴充卡）
- Prototype（原型）
- Iterator（疊代器）
- Observer（觀察者）
- Brige（橋接模式）
- Single（單例模式）
- Composite（組合模式）
- Facade（外觀模式）
- Decorator（裝飾器模式）
- Proxy（代理模式）
- 作用
- 應付軟考No Problem
多态
在面向對象技術中，對象在收到消息後要予以響應，不同的對象收到同消息可聲生完全不同的結果，這一現象稱為多态。 多态有多種不同的形式，其中參數多态和包含多态稱為通用多态，過載多态和強制多态稱為特定多态。
參數多态應用比較廣泛，被稱為最純的多态。這是因為同一對象、函數或過程能以一緻的形式用于不同的類型。 包含多态最常見的例子就是子類型化，即一個類型是另一類型的子類型。過載多态是同變量被用來表示不同的功能（就是我們說的重載overload）， 通過上下文以決定一個類所代表的功能。即通過文法對不同語義的對象使用相同的名，編譯能夠消除這一模糊強制多态（類型轉換，int 型轉float型）是通過語義操作把一個 變元的類型加以變換，以符合個函數的要求， 如果不做這強制性變換将出現類型錯誤。 類型的變換可在編譯時完成，通常是隐式地進行，當然也可以在動态運作時來做。
類與類之間的關系
類與類之間的關系，常見的有依賴關系、泛化關系(繼承關系)、組合關系、聚合關系、實作關系等。
(1)依賴關系。
有兩個元素X、Y，如果修改元素X的定義可能會引起對另一個元素Y的定義的修改，則稱元素Y依賴(Dependency)于元素X。在UML中，使用帶箭頭的虛線表示依賴關系，如圖下所示，
------------------------------------------------------------>：依賴關系的圖示
在類中，依賴由各種原因引起，例如，一個類向另 一個類發消息: 一個類是另一個類的資料成員；一個類是另一個類的某個操作參數。如果-一個類的接口改變，它發出的任何消息可能不再合法。
(2)泛化關系。
泛化關系描述一般事物與該事物中的特殊種類之間的關系，也就是父類與子類之間的關系。繼承關系是泛化關系的反關系，也就是說，子類是從父類繼承的，而父類則是子類的泛化。在UML中，使用帶空心箭頭的實線表示泛化關系，箭頭指向父類，如下圖所示。
————————————————————>:泛化關系表示
在UML中，對泛化關系有3個要求。
- 子類應與父類完全一緻，父類所具有的關聯、屬性和操作，子類都應具有；
- 子類中除了有與父類一緻的資訊外，還包括額外的資訊；
- 可以使用父類執行個體的地方，也可以使用子類執行個體。
(3)聚合關系。
聚合（Aggregation）是一種特殊形式的關聯，是傳遞與反對稱的。聚合表示類之間的關系是整體與部分的關系，例如，一輛轎車包含4個車輪、一個方向盤、一個發動機和一個底盤，就是聚合的一個例子。在UML中，使用一個帶空心菱形的實線表示聚合關系，空心菱形指向的是代表“整體”的類。如下圖所示：
（4）組合關系
如果聚合關系中表示“部分”的類的存在與否，與表示“整體”的類有這緊密的關系，例如“公司”與“部門”之間的關系，那麼就應該使用“組合”關系來表示這種關系。在UML中，使用帶實心的菱形表示組合關系，如圖：
（5）實作關系
實作關系将說明和實作聯系起來。接口是對行為而非實作的說明，而類中則包含了實作的結構。一個或多個類可以實作一個接口，而每個類分别實作接口中的操作。
用例與用例之間的關系
用例之間存在3種關系，分别是包含關系、擴充關系和泛化關系。
包含關系。當可以從兩個或兩個以一的用例中提取公共行為時，應該使用包含關系來表示它們。其中這個提取出來的公共用例稱為抽象用例，而把原始用例稱為基本用例或基礎用例。包含關系的個重要特征， 就是被抽象出來的用例是基礎用例必須的部分，不能或缺。本題的描述就是一個包含關系。
擴充關系。如果一個用例明顯地混合了兩種或兩種以上的不同場景，即根據情況可能發生多種分支，則可以将這個用例分為一個基本用例和一個或多個擴充用例，這樣使描述可能更加清晰。擴充關系的一個重要特征，就是抽取的用例相對于基礎用例來說不是必須的。
泛化關系。當多個用例共同擁有一種類似的結構和行為的時候，可以将它們的共抽象成為父用例，其他的用例作為泛化關系中的子用例。在用例的泛化關系中，子用例是父用例的一種特殊形式， 子用例繼承了父用例所有的結構、行為和關系。例如，某員進行課程注冊時，假設既可以通過現場注冊，也可以通過網上注冊，則“注冊課程”用例就是“現場注冊”用例和“網上注冊”用例的泛化。
面向對象的七大原則
面向對象有七大原則，分别是：單一職責原則
(1）單職責原則(SRP)
就一個類來說，應該僅有一個引起它變化的原因。也就是說，一個類應該隻有一個職責。如果有多個職責，那麼就相當于把這些職責耦合在一起，一個職責的變化就可能削弱或抑制了這個類完成其他職責的能力，引起類的變化的原因就會有多個。是以在構造一個類時， 将類的不同職責分離至兩個或多個類中(或者接口中)，確定引起該類變化的原因隻有一一個。
(2)開閉原則(OCP)
軟體組成實體應該是可擴充的，但是不可修改。開放-封閉原則認為應該試圖設計永遠也不需要改變的子產品。可以添加新代碼來擴充系統的行為，不能對已有的代碼進行修改。這個原則很好的實作了而向對象的封裝性和可重用性。
(3)替換原則（LSP）
子類應當可以替換父類并出現在父類能夠出現的任何地方。這個原則是Liskov于1987 年提出的設計原則。它同樣可以從Bertrand Meyer的DBC(Design by Contract)的概念推出。以圓和橢圓為例，圓是橢圓的一個特殊子類。是以任何出現橢圓的地方，圓均可以出現。但反過來就可能行不通。
(4)依賴倒置原則(DIP)
在進行業務設計時，與特定業務有關的依賴關系應該盡量依賴接口和抽象類，而不是依賴于具體類。具體類隻負責相關業務的實作，修改具體類不影響與特定業務有關的依賴關系。在結構化設計中，可以看到底層的子產品是對高層抽象子產品的實作，這說明，抽象的子產品要依賴具體實作相關的子產品，底層子產品的具體實作發生變動時将會嚴重影響高層抽象的子產品，顯然這是結構化方法的一一個“硬傷”。面向對象方法的依賴關系剛好相反，具體實作類依賴于抽象類和接口。為此，在進行業務設計時，應盡量在接口或抽象類中定義業務方法的原型，并通過具體的實作類(子類)來實作該業務方法:業務方法内容的修改将不會影響到運作時業務方法的調用。
(5)接口分離原則(ISP)
采用多個與特定客戶類有關的接口比采用一個通用的涵董多個業務方法的接口要好。ISP原則是另外一個支援諸如COM等元件化的使能技術。缺少ISP,元件、類的可用性和移植性将大打折扣。這個原則的本質相當簡單。如果擁有一一個針對多個客戶的類，為每一一個客戶建立特定 業務接口，然後使該客戶類繼承多個特定業務接口将比直接加載客戶所需所有方法有效。
(6)組合重用原則
就是能用組合實作的地方，盡量用組合來實作，而不要使用繼承來擴充功能，因為組合能更好地實作封裝，比繼承具有更大的靈活性和更穩定的結構。
(7)迪米特原則
指一個對象應該對 于其他對象有最少的了解，即類與類之間的依賴低，或者說沒有依賴。這樣做的好處就是可以有效地降低類之間的耦合要求。
UML基礎
UML中的4種事物
1、結構事物是UML模型中的名次。他們通常是模型的靜态部分，描述概念或實體元素。
2、行為事物是UML模型的動态部分。他們是模型中的動詞，描述了跨越時間和空間的行為。
3、分組事物是UML模型的組織部分。他們是一些有模型分解成的‘“盒子”。
4、注釋事物是UML模型的解釋部分。他們是用來描述、說明和标注模型的任何元素。
UML對系統架構的定義是系統的組織結構，包括系統分解的組成部分，以及它們的關聯性、互動機制和指導原則等提供系統設計的資訊。具體來說，就是指以下5個系統視圖
(1)邏輯視圖。邏輯視圖也稱為設計視圖，表示設計模型中在架構方面具有重要意義的部分，即類、子系統、包和用例實作的子集。
(2)程序視圖。程序視圖是可執行線程和程序作為活動類的模組化，是邏輯視圖的一次執行執行個體， 描述了并發與同步結構。
(3)實作視圖。實作視圖對組成基于系統的實體代碼的檔案和構件進行模組化。
(4)部署視圖。部署視圖把構件部署到一組實體結點上，表示軟體到硬體的映射和分布結構。
(5)用例視圖。用例視圖是最基本的需求分析模型。
UML中的14中圖
UML2.0中的14種視圖可以分為結構性視圖(靜态)和行為性視圖(動态)兩種。結構領城主要是對系統中的結構成員及其互相關系進行描述:而行為領域則描述了系統随時間變化的行為。
結構性視圖包括類圖，對象圖、包圖，組合結構圖、構件圖、部署圖和制品圖，而行為性視圖包括用例圖，順序圖、通信圖、定時圖、狀态圖、活動圖、互動概覽圖。其中順下圖、通信圖、定時圖和互動概覽圖又統稱為互動圖。
在UML2.0包括14種圖，分别列舉如下:
(1)類圖(Class Diagram)
類圖描述組類、接口、協作和它們之間的關系。在00系統的模組化中，最常見的圖就是類圖。類圖給出了系統的靜态設計視圖，活動類的類圖給出了系統的靜态程序視圖。
###(2)對象圖(Object Diagram)
對象圖描述組對象及它們之間的關系。 對象圖描述了在類圖中所建立的事物執行個體的靜态快照。和類圖一樣，這些圖給出系統的靜态設計視圖或靜态程序視圖，但它們是從真實案例或原型案例的角度建立的。
(3)構件圖(Component Diagram)
構件圖描述一個封裝的類和它的接口、 端口，以及由内嵌的構件和連接配接件構成的内部結構，構件圖用于表示系統的靜态設計實作視圖。對于由小的部作建構大的系統來說，構作圖是很重要的。構件圖是類圖的變體。
(4)組合結構圖Composite Structure Diagram)
組合結構圖描述結構化類(如構件或類)的内部結構，包括結構化類 與系統其餘部分的互動點。組合結構圖用于畫出結構化類的内部内容。
(5)用例圖(Use Case Diagram)
用倒圖描述組用例、參與者及它們之間的關系。用例圖給出系統的靜态用例視圖，這些圖在對系統的行為進行組織和模組化時是非常重要的。
(6)順序圖(Sequence Diagram序列圖)
順序圖是一種互動圖（Interaction Diagram），互動圖展現了一種互動， 由一組對象或參與者以及它們之間可能發送的消息構成。互動圖專注于系統的動态視圖。順序圖是強調消息的時間次序的互動圖。
(7)通信圖（Communication Diagram）
通信圖也是一種互動圖，強調收發消息的
對象或參與者的結構組織。改圖反映了對象之間的消息互動，與順序圖相似，但與順序圖不同的是。協代圍不但描述了對象之間的互動，還描述了互動的對象之間的連結關系。即通信圖時反映了系統的動态和靜态特征，在UML1.X版本中，通信圖稱為協作圖(Collaboration Diagram)。
(8)定時圖(Timing Diagram,計時圖)
定時圖也是一種互動圖， 強調消息跨越不同對象或參與者的實際時間，而不僅僅隻是關心消息的相對順序。
(9)狀态圖( State Diagram)。
狀态圖描述個狀态機， 由狀态、轉移、事件和活動組成。 狀态圖給出了 對象的動态視圖。它對于接口、類或協作的行為模組化尤為重要， 而且它強調事件導緻的對象行為，有助于對反應式系統模組化。
(10)活動圖(Activity Diagram)
活動圖将程序或其他計算結構展示為計算内部一步步的控制流和資料流。活動圖專注于系統的動态視圖。它對系統的功能模組化和業務流程模組化特别重要，并強調對象間的控制流程。
(11)部署圖(Deployment Diagram)
部署圖描述對運作時的處理結點及在其中生存的構件的配置。部署圖給出了架構的靜态部署視圖，通常一個結點包含 一個或多個部暑圖。
(12)制品圖(Artifact Diagram)
制品圖描述計算機中一個系統的實體結構。制品包括檔案、資料庫和類似的實體比特集合。制品圖通常與部署圖一起使用。 制品也給出了它們實作的類和構件。
(13)包圖(Package Diagram)
包圖描述由模型本身分解而成的組織單元，以及它們之間的依賴關系。
(14)互動概覽圖(Interaction Overview Diagram)
互動概覽圖是活動圖和順序圖的混合物。
設計模式
Adapter（擴充卡）
該設計模式的意圖是将一個類的接口轉換成客戶希望的另外一個接口。Adapter 模式使得原本由于接口不相容而不能一起工作的那些類可以一起工作。
适用性:想使用一個已經存在的類，而它的接口不符合需求。
想建立一個可以複用的類， 該類可以與其他不相 關的類或不可預見的類(即那些接口可能不一定相容的類) 協同工作。(僅适用于對象Adapter)想使用些已經存在的子類，但是不可能對每一個都進行子類化以比對它們的接口。對象擴充卡可以适配它的父類接口。
Prototype（原型）
(2) Prototype (原型)設計模式的意圖是用原型執行個體指定建立對象的種類，并且通過複制這些原型建立新的對象。
适用性:當要執行個體化的類是在運作時刻指定時。例如，通過動态裝載:或為了避免建立一個與産品類層次平行的工廠類層次時:或當一個類的執行個體隻能有幾個不同狀态組合中的一種時。建立相應數目的原型并克隆它們可能比每次用合适的狀态手工執行個體化該類更友善一-些。
Iterator（疊代器）
(3) Iterator (疊代器)設計模式的意圖是提供一種 方法順序通路一個聚合對象中各個元素，而又不需暴露該對象的内部表示。
适用性:通路一個聚合對象的内容而無須暴露它的内部表示。疊代器模式支援對聚合對象的多種周遊。也為周遊不同的聚合結構提供一個統的接口(即支援多态疊代)。
Observer（觀察者）
(4) Observer (觀察者)設計模式，定義對象間的= 種對多的依賴關系,當一 一個對象的狀态發生改變時，所有依賴于它的對象都得到通知并被自動更新。
适用性:當一個抽象模型有兩個方面，其中一不方面依賴丁另方面。 将這兩者封裝在獨立的對象中以使它們可以各自獨立地改變和複用。以下兩種情況比較适合觀察者模式:一個是當對一個對象的改變需要同時改變其他對象，而不知道具體有多少對象有待改變:另一個是當一個對象必須通知其他對象，而它又不能假定其他對象是誰。換言之，你不希望這些對象是緊密耦合的。
Brige（橋接模式）
橋樓模式的意圖是将抽象部分與它的實作部分分離。橋接模式的适用性如下:
(1)避免抽象方法和實作方法綁定在一起。
(2)類的抽象以及它的實作都應該可以通過生成子類的方法加以擴充。
(3)對一個抽象的實作部分的修改應對客戶不産生影響，即客戶的代碼不必重新
編譯。
(4)想在多個對象間共享實作(可能使用引用計數)，但同時要求客戶并不知道這一點。
橋接模式是把繼承關系變成合成/聚合關系。手機可以按照品牌來分類，則有手機品牌M,手機品牌N之分，現在的每個手機都有很多軟體，如通信錄，手機遊戲等。運用橋接模式，可把手機系統劃分為品牌和軟體，使它們可以獨立的變化。
q橋接模式可以從接口中分離實作功能，使得設計更具有擴充性，這樣，客戶調用方法時根本不需要知道實作的細節.橋接模式的缺陷是抽象類和實作類的雙向連接配接使得運作速度減慢。
Single（單例模式）
單側模式確定其個一類隻有一個執行個體， 而且自行執行個體化并向整個系統提供這個執行個體。這個類稱為單例類，它提供全局通路的方法。單例模式的要點有三個:一是某個類隻能有一個執行個體；二是它必須自選建立這個執行個體；三是它必須自行向整個系統提供這個執行個體。
Composite（組合模式）
組合(Composite)設計模式組合多個對象形成樹形結構以表示整體部分的結構層次。合成模式對單個對象和合成對象的使用具有一緻性。
Facade（外觀模式）
外觀(Facade) 模式，有稱為門面模式，其提供了一個統一一的接口去通路多個子系統的多個不同的接口。外觀模式定義了一個高層次的接口，使得子系統更容易被使用。
Decorator（裝飾器模式）
裝飾器模式是動态地給一個對象添加一些額外職責。在需要某個對象而不是整個類添加一些功能時使用。這種模式對增加功能比生成子類更加靈活。
Proxy（代理模式）
代理模式通過提供與對象相同的接口來控制對這個對象的通路，以使得在确實需要這個對象時才對他進行建立和初始化。
作用
設計模式主要有以下幾個方面的作用:
(1)重用設計，重用設計比重用代碼更有意義，它會自動帶來代碼重用。
(2)為設計提供共同的詞彙，每個模式名就是一個設計詞彙，其概念是的程式員間的交流更加友善。
(3)在開發文檔中采用模式詞彙可以讓其他人更容易了解你的想法和做法，編寫開發文檔也更加容易。
(4)應用設計模式可以讓重構系統變得容易，可確定開發正确的代碼，并降低在設計或實作中出現錯誤的可能。
(5)支援變化，可以為重寫其他應用程式提供很好的系統架構。(6)正确使用設計模式，可以節省大量時間。
另外，設計模式還有适應需求變化的優點，如職責鍊模式，當系統業務流程有變化時，隻需要很少的調整即可達到目的。
應付軟考No Problem
每種設計模式都有特定的意圖，描述一個在我們周圍不斷重複發生的問題，以及該問題的解決方案的核心，使該方案能夠重用而不必做重複勞動。
責任鍊(Chain of Resposiblity)模式使多個對象都有機會處理請求，進而避免請求的發送者和接收者之間的耦合關系，将這些對象連成條鍊， 并沿着這條鍊傳遞該請求，直到有一個對象處理它為止。
指令(Command)模式将- -一個請求封裝為一個對象，進而使得使用者可以采用不同的請求對客戶進行參數化:對請求排隊或記錄請求日志，以及支援可撤銷的操作。
抽象工廠(Abstract Factory)模式提供一- 個建立一系列相關或互相依賴對象的接口，而無需指定它們具體的類。
觀察者(Observer)模式定義對象間的一種一對多 的依賴關系，當一-個對象的狀态發生改變時，所有依賴于它的對象都得到通知并被自動更新。
原型(Prototype) 模式用原型執行個體指定建立對象的種類，并且通過拷貝這個原型來建立新的對象。
工廠方法(Factory Method)定義一個用于建立對象的接口， 讓子類決定将哪一個類執行個體化，使一個類的執行個體化延遲到其子類。
單例(Singleton)模式是指系統運作過程中，一個類隻有 一個對象執行個體。
生成器(Builder) 模式将一個複雜對象的建構與它的表示分離，使得同樣的建構過程可以建立不同的表示。
擴充卡(Adapter)模式将一個類的接口轉換成客戶希望的另外一個接口， 使得原本由于接口不相容而不能一起工作的那些類可以一起工作。
橋接(Brige)模式将抽象部分與其實作部分分離，使它們都可以獨立地變化。組合(Composit)模式将對象組合成樹形結構以表示“部分整體” 的層次結構，使得使用者對單個對象群組合對象的使用具有一緻性。
裝飾器Ceonmto)) 模式描述了以透明圍欄來支援修飾的類和對象的關系，動态地給個對象添加一些額外的職責， 從增加功能的角度來看，裝飾器模式相比生成子類更加靈活。
政策(Strategy)設計模式定義一系列算法，把它們一個個封裝起來，并且使它們可以互相替換。這一模式使得算法可獨立與它的客戶而變化。
抽象工廠(Abstract Factory)模式提供一個建立一系列相關或互相依賴對象的接口，而無需指定他們具體的類。
狀态(State)模式是使得一個對象在其内部狀态改變時通知調用另一個類中的方法改變其行為，使這個對象看起來如同修改了它的類。
組合(Composite)模式将對象組合成樹形結構以表示“部分-整體”的層次結構，使得使用者對單個對象群組合對象的使用具有一緻性。元件Component為組合的對象聲明接口，通常定義父元件引用。
****