面向對象的分析與設計課程學習的內容OO設計原則UML設計圖及RoseRational工具OO設計模式典型項目的分析與設計學習方法掌握主要OO原則的原理和應用要點改變java編程習慣學會設計Rational工具的使用；掌握類圖、用例圖、順序圖、活動圖的設計熟練掌握MVC設計方法熟練掌握數(shù)據(jù)庫編程深化了解API，深化基于API的編程反復實踐典型模式應用于項目的分析和設計考核基于典型項目的考察:項目的分析與方案設計UML典型圖項目代碼中基本原則的應用項目設計中模型的使用OOP編程要點

OOP追求的目標：可用性、完整性、健壯性、有效性、可伸縮性、可讀性、可重用性、簡潔性、可維護性、可擴充行OOP典型特點：封裝性、繼承性、重載、屬性和修飾符、多態(tài)、重構、抽象類接口、集合、泛型、委托與事件實現(xiàn)一個最簡單的實例計算立體型幾何體體積要點:分析其中的耦合性、程序的復用性“臟代碼”分析單一職責原則(SRP原則)就一個類而言，應該只有一個引起它變化的原因；失敗的案例：界面處理類+數(shù)據(jù)庫操作+文件讀寫+業(yè)務流程控制類比：多功能手機、集成主板的電腦—壞一處就全壞經驗：類的設計傾向于越小越好解釋:如果一個類承擔的職責過多，就等于把這些職責耦合在一起。一個職責的變化可能會引起消弱或抑制這個類完成其他職責的功能。這種耦合會導致脆弱的設計。當變化發(fā)生時，設計會遭到意想不到的破壞。開-閉原則（核心原則）軟件實體(類、模塊、方法）應該可以擴展，但不可以修改；換個說法:類對擴展是開放的,對修改是封閉的;用extends和implements等開放，用private封閉實際使用：1.隨時準備修改：改變是合理的；2.原來的代碼一般不要改動，合理的方法是基于原先的代碼產生新的類3.設計之初就準備好應對變化，用抽象來隔離變化，減少耦合。開-閉原則的運用:寫一個相對固定的內核;不斷產生新的類，當修改發(fā)生時；新的類給予接口或抽象類創(chuàng)建；理解:面向接口編程依賴倒轉原則抽象不應該依賴于細節(jié)，細節(jié)應該依賴于抽象；----針對接口編程，不要對實現(xiàn)編程解釋：1.高層類不應該依賴低層類；兩者都應依賴于抽象；2.抽象不應該依賴細節(jié)；細節(jié)應該依賴抽象反轉實例:電話指揮修電腦，誰依賴誰？抽象與實現(xiàn)：電腦主板-總線插槽-PIC卡的實例—抽象不依賴細節(jié)，細節(jié)依賴抽象。依賴止于接口--用接口消除強耦合AB依賴AB依賴I依賴用接口消除強耦合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ā)式原則

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

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

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

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

UML圖類圖案例分析好友管理系統(tǒng)中的類圖分析好友管理系統(tǒng)中消息傳送過程分析--登錄過程分析--查詢過程分析--增加過程過程時序圖例子時序圖例子2時序圖例子3設計時序圖一般方法盡力保持消息的順序從左到右排列將分類器分