多媒體課件第三講課件時序圖第一頁，共二十五頁，編輯于2023年，星期日課程學習的內容OO設計原則UML設計圖及RoseRational工具OO設計模式典型項目的分析與設計第二頁，共二十五頁，編輯于2023年，星期日學習方法掌握主要OO原則的原理和應用要點改變java編程習慣學會設計Rational工具的使用；掌握類圖、用例圖、順序圖、活動圖的設計熟練掌握MVC設計方法熟練掌握數(shù)據(jù)庫編程深化了解API，深化基于API的編程反復實踐典型模式應用于項目的分析和設計第三頁，共二十五頁，編輯于2023年，星期日參考書面向對象軟件工程與UML,李飛躍,人民郵電出版社(高職教材）UML與軟件建模,徐寶文,清華大學出版社（重點大學教材）面向對象設計原理與模式，（美)DaleSkrien著，清華大學出版社（國外經(jīng)典教材)Java設計模式,耿祥義,清華大學出版社大話設計模式，程杰，清華大學出版社第四頁，共二十五頁，編輯于2023年，星期日考核基于典型項目的考察:項目的分析與方案設計UML典型圖項目代碼中基本原則的應用項目設計中模型的使用第五頁，共二十五頁，編輯于2023年，星期日OOP編程要點

OOP追求的目標：可用性、完整性、健壯性、有效性、可伸縮性、可讀性、可重用性、簡潔性、可維護性、可擴充行OOP典型特點：封裝性、繼承性、重載、屬性和修飾符、多態(tài)、重構、抽象類接口、集合、泛型、委托與事件第六頁，共二十五頁，編輯于2023年，星期日實現(xiàn)一個最簡單的實例計算立體型幾何體體積要點:分析其中的耦合性、程序的復用性“臟代碼”分析第七頁，共二十五頁，編輯于2023年，星期日OO基本原則單一職責原則要點:…開-閉原則依賴倒轉原則里氏替換原則面向抽象原則多用組合少用繼承原則迪米特原則高內聚/低耦合原則合成/聚集復用原則接口隔離原則第八頁，共二十五頁，編輯于2023年，星期日單一職責原則(SRP原則)就一個類而言，應該只有一個引起它變化的原因；失敗的案例：界面處理類+數(shù)據(jù)庫操作+文件讀寫+業(yè)務流程控制類比：多功能手機、集成主板的電腦—壞一處就全壞經(jīng)驗：類的設計傾向于越小越好解釋:如果一個類承擔的職責過多，就等于把這些職責耦合在一起。一個職責的變化可能會引起消弱或抑制這個類完成其他職責的功能。這種耦合會導致脆弱的設計。當變化發(fā)生時，設計會遭到意想不到的破壞。第九頁，共二十五頁，編輯于2023年，星期日開-閉原則（核心原則）軟件實體(類、模塊、方法）應該可以擴展，但不可以修改；換個說法:類對擴展是開放的,對修改是封閉的;用extends和implements等開放，用private封閉實際使用：1.隨時準備修改：改變是合理的；2.原來的代碼一般不要改動，合理的方法是基于原先的代碼產生新的類3.設計之初就準備好應對變化，用抽象來隔離變化，減少耦合。第十頁，共二十五頁，編輯于2023年，星期日開-閉原則的運用:寫一個相對固定的內核;不斷產生新的類，當修改發(fā)生時；新的類給予接口或抽象類創(chuàng)建；理解:面向接口編程第十一頁，共二十五頁，編輯于2023年，星期日里氏替換原則子類型必須能替換掉它們的父類型分析：“企鵝不是鳥”––子類型必須包含父類型的全部特征

第十二頁，共二十五頁，編輯于2023年，星期日依賴倒轉原則抽象不應該依賴于細節(jié)，細節(jié)應該依賴于抽象；----針對接口編程，不要對實現(xiàn)編程解釋：1.高層類不應該依賴低層類；兩者都應依賴于抽象；2.抽象不應該依賴細節(jié)；細節(jié)應該依賴抽象反轉實例:電話指揮修電腦，誰依賴誰？抽象與實現(xiàn)：電腦主板-總線插槽-PIC卡的實例—抽象不依賴細節(jié)，細節(jié)依賴抽象。第十三頁，共二十五頁，編輯于2023年，星期日依賴止于接口--用接口消除強耦合AB依賴AB依賴I依賴用接口消除強耦合第十四頁，共二十五頁，編輯于2023年，星期日OO的基本原則89、面向對象的基本設計原則

1)LSP(TheLiskovSubstitutionPrinciple):Liskov替換原則

子類不能添加任何父類沒有的附加約束。子類對象必須可以替換基類對象。

在可能的情況下，由抽象類(接口)繼承。

抽象類與具體類

只要有可能，不要從具體類繼承；

行為集中的方向是向上的(抽象類)；

數(shù)據(jù)集中的方向是向下的(具體類)。

2)OCP(TheOpen-ClosePrinciple):開放-封閉原則

對于擴展是開放的(Openforextension)

對于更改是封閉的(Closedformodification)

關鍵在于抽象

抽象預見了可能的所有擴展(閉)

由抽象可以隨時導出新的類(開)

OCP是OOD中很多說法的核心。

LSP是OCP成為可能的主要原則之一。

3)SRP單一職責原則(TheSingleResponsibilityPrinciple)

一個類，應該僅有一個引起它變化的原因。

體現(xiàn)了內聚性(Cohesion)：一個模塊的組成元素之間的功能相關性。

違反SRP原則會帶來物理依賴的缺點。

使得每個類僅有一個職責。

4)ISP接口隔離原則(TheInterfaceSegregationPrinciple)

客戶應該僅知道所需要要的接口。

一個類實現(xiàn)多個接口，避免“肥接口(fatinterface)”

使用委托分離接口,Adapter模式;使用多重繼承分離接口。

本質：

使用多個專門的接口比使用單一的接口好。

一個類對另一個類的依賴性應當是建立在最小的接口上的。

避免接口污染(InterfacePollution)

5)DIP依賴倒置原則(TheDependencyInversionPrinciple)

高層模塊不依賴于低層模塊，二者都依賴于抽象。

抽象不應該依賴于細節(jié)，細節(jié)應該依賴于抽象。

針對接口編程，而不是針對實現(xiàn)編程。

Booch：所有結構良好面向對象架構都具有清晰地層次定義，每個層次通過一個定義良好的、受控的接口向外提供了一組類聚的服務。

6)啟發(fā)式原則

依賴于抽象——依賴關系都應終止于抽象類或者接口。

任何變量都不應該擁有指向具體類的指針或者引用。

任何類都不應該從具體類派生。

任何方法都不應該改寫其任何基類中已經(jīng)實現(xiàn)的方法。

第十五頁，共二十五頁，編輯于2023年，星期日UML中的類圖類圖中的6種關系1.繼承(泛化)關系;2.實現(xiàn)關系;3.依賴關系;4.關聯(lián)關系;5.組合關系6.聚合關系;基本畫法:1.指向實體的關系用實線；指向虛體（接口和抽象類）的關系用虛擬線；2.箭頭指向時間上先定義的類

第十六頁，共二十五頁，編輯于2023年，星期日UML圖第十七頁，共二十五頁，編輯于2023年，星期日類圖第十八頁，共二十五頁，編輯于2023年，星期日案例分析好友管理系統(tǒng)中的類圖分析好友管理系統(tǒng)中消息傳送過程分析--登錄過程分析--查詢過程分析--增加過程過程第十九頁，共二十五頁，編輯于2023年，星期日序列圖—系統(tǒng)的動態(tài)過程分析時序圖時序圖展示了幾個對象之間的動態(tài)交互關系。它主要是用來顯示對象之間發(fā)送消息的順序，它還顯示了對象之間的交互，即系統(tǒng)執(zhí)行的某一特定點所發(fā)生的事。第二十頁，共二十五頁，編輯于2023年，星期日時序圖例子第二十一頁，共二十五頁，編輯于2023年，星期日時序圖例子2第二十二頁，共二十五頁，編輯于2023年，星期日時序圖例子3第二十三頁，共二十五頁，編輯于2023年，星期日時序圖中包括如下元素：類角色，生命線，激活期和消息

1，類角色(ClassRole)

類角色代表時序圖中的對象在交互中所扮演的角色，位于時序圖頂部和對象代表類角色。類角色一般代表實際的對象2，生命線(Lifeline)

生命線代表時序圖中的對象在一段時期內的存在。時序圖中每個對象和底部中心都有一條垂直的虛線，這就是對象的生命線，對象間的消息存在于兩條虛線間。3，激活期(Activation)

激活期代表時序圖中的對象執(zhí)行一項操作的時期，在時序圖中每條生命線上的窄的矩形代表活動期。它可以被理解成C語言語義中一對花括號“{}”中的內容4，消息(Message)

消息是定義交互和協(xié)作中交換信息的類，用于對實體間的通信內容建模，信息用于在實體間傳遞信息。允許實體請求其他的服務，類角色通過發(fā)送和接受信息進行通信第二十四頁，