?
軟件開(kāi)發(fā)的相關(guān)技術(shù)
??????????????????????作者：naven
2005-5-10
?
1
、
Rational
統(tǒng)一開(kāi)發(fā)過(guò)程（
Rational Unified Process
簡(jiǎn)稱
RUP
）
是軟件開(kāi)發(fā)隊(duì)伍的最佳實(shí)踐
?
什么是
Rational Unified Process
RUP
是軟件工程化過(guò)程它提供了在開(kāi)發(fā)機(jī)構(gòu)中分派任務(wù)和責(zé)任的紀(jì)律化方法它的目標(biāo)是在可預(yù)見(jiàn)的日程和預(yù)算前提下確保滿足最終用戶需求的高質(zhì)量產(chǎn)品
RUP
是有效使用
Unified Modeling Language
（
UML
）的指南。是良好溝通需求體系結(jié)構(gòu)和設(shè)計(jì)的工業(yè)標(biāo)準(zhǔn)語(yǔ)言。
UML
是由
Rational
軟件公司創(chuàng)建現(xiàn)在由標(biāo)準(zhǔn)化對(duì)象管理機(jī)構(gòu)（
OMG
）維護(hù)
?
“統(tǒng)一過(guò)程”概述
“統(tǒng)一過(guò)程”是軟件開(kāi)發(fā)過(guò)程。軟件開(kāi)發(fā)過(guò)程是將用戶的需求轉(zhuǎn)化為一個(gè)軟件系統(tǒng)的一系列活動(dòng)的總稱。然而，“統(tǒng)一過(guò)程”不僅僅是一個(gè)過(guò)程。它是一個(gè)通用過(guò)程框架，可以應(yīng)付種類廣泛的軟件系統(tǒng)、不同的應(yīng)用領(lǐng)域、不同的組織類型、不同的性能水平和不同的項(xiàng)目規(guī)模。
“統(tǒng)一過(guò)程”是基于組件的，這意味著利用它開(kāi)發(fā)的軟件系統(tǒng)是由組件構(gòu)成的，組件之間通過(guò)定義良好的接口相互聯(lián)系
。
在準(zhǔn)備軟件系統(tǒng)的所有藍(lán)圖的時(shí)候，“統(tǒng)一過(guò)程”使用的是“統(tǒng)一建模語(yǔ)言（
Unified Modeling anguage
）”。事實(shí)上，
UML
是“統(tǒng)一過(guò)程”的有機(jī)組成部分——它們是被同步開(kāi)發(fā)的
。
然而，真正使“統(tǒng)一過(guò)程”與眾不同的方面可以用三個(gè)句話來(lái)表達(dá)：它是用例驅(qū)動(dòng)的、以基本架構(gòu)為中心的、迭代式和增量性的。正是這些特征使得“統(tǒng)一過(guò)程”卓爾不群。
“統(tǒng)一過(guò)程”是用例驅(qū)動(dòng)的“統(tǒng)一過(guò)程”是用例驅(qū)動(dòng)的“統(tǒng)一過(guò)程”是用例驅(qū)動(dòng)的“統(tǒng)一過(guò)程”是用例驅(qū)動(dòng)的開(kāi)發(fā)軟件系統(tǒng)的目的是要為該軟件系統(tǒng)的用戶服務(wù)。因此，要?jiǎng)?chuàng)建一個(gè)成功的軟件系統(tǒng)，我們必須明白其潛在用戶需要什么
。
?
2
、統(tǒng)一模語(yǔ)言
UML
概述
標(biāo)準(zhǔn)建模語(yǔ)言
UML
的重要內(nèi)容可以由下列五類圖
(
共
9
種圖形
)
來(lái)定義
:
·第一類是用例圖
,
從用戶角度描述系統(tǒng)功能
,
并指出各功能的操作者。
·第二類是靜態(tài)圖
(Static diagram),
包括類圖、對(duì)象圖和包圖。其中類圖描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。不僅定義系統(tǒng)中的類
,
表示類之間的聯(lián)系如關(guān)聯(lián)、依賴、聚合等
,
也包括類的內(nèi)部結(jié)構(gòu)
(
類的屬性和操作
)
。類圖描述的是一種靜態(tài)關(guān)系
,
在系統(tǒng)的整個(gè)生命周期都是有效的。對(duì)象圖是類圖的實(shí)例
,
幾乎使用與類圖完全相同的標(biāo)識(shí)。他們的不同點(diǎn)在于對(duì)象圖顯示類的多個(gè)對(duì)象實(shí)例
,
而不是實(shí)際的類。一個(gè)對(duì)象圖是類圖的一個(gè)實(shí)例。由于對(duì)象存在生命周期
,
因此對(duì)象圖只能在系統(tǒng)某一時(shí)間段存在。包由包或類組成
,
表示包與包之間的關(guān)系。包圖用于描述系統(tǒng)的分層結(jié)構(gòu)。
·第三類是行為圖
(Behavior diagram),
描述系統(tǒng)的動(dòng)態(tài)模型和組成對(duì)象間的交互關(guān)系。
·第四類是交互圖
(Interactive diagram),
描述對(duì)象間的交互關(guān)系。
·第五類是實(shí)現(xiàn)圖
( Implementation diagram )
。
?
RUP
及
UML
缺點(diǎn)：過(guò)于復(fù)雜甚至有些啰嗦。
?
?
3
、面向?qū)ο筌浖_(kāi)發(fā)和過(guò)程
A
代碼是軟件開(kāi)發(fā)的基礎(chǔ)
編碼是軟件開(kāi)發(fā)過(guò)程中最基本、最底層的技藝，然而也是最重要的技藝。任何一個(gè)領(lǐng)域的專家都需要花費(fèi)大量的時(shí)間來(lái)進(jìn)行基本技藝的鍛煉，木匠需要花費(fèi)大量的時(shí)間來(lái)鍛煉他們對(duì)各種工具的掌握，廚師則需要練習(xí)刀工和火候。程序員也是一樣的，對(duì)我們來(lái)說(shuō)，語(yǔ)言的各種特性必須要了然于胸。而對(duì)軟件的管理也需要從代碼做起。
面向?qū)ο蟮拇a已經(jīng)在現(xiàn)在的軟件開(kāi)發(fā)中占據(jù)了主流的位置，面向?qū)ο蟮乃悸芬灿衅鋬?yōu)勢(shì)所在，就像后文所討論的，面向?qū)ο蟠a有著非面向?qū)ο蟠a的很多優(yōu)勢(shì)，而軟件業(yè)中很多新的思潮的產(chǎn)生，也都是基于面向?qū)ο笳Z(yǔ)言的，所以我們關(guān)注的代碼將是面向?qū)ο蟠a。
編寫(xiě)優(yōu)秀的面向?qū)ο蟠a并不是一件容易的事情，優(yōu)秀的
OO
代碼如行云流水，糟糕的
OO
代碼讓人覺(jué)得渾身起雞皮疙瘩。編寫(xiě)優(yōu)秀的
OO
代碼要求程序員有一定的自我修養(yǎng)，能夠以抽象的思路看待問(wèn)題，找到問(wèn)題的核心并對(duì)問(wèn)題域進(jìn)行分解。它強(qiáng)調(diào)的是一種解題的思路，但這個(gè)解不是唯一的。
編寫(xiě)優(yōu)秀
OO
代碼雖難，但還有更難的事情，就是讓整個(gè)開(kāi)發(fā)團(tuán)隊(duì)都產(chǎn)出優(yōu)秀的
OO
代碼。
?
B
面向?qū)ο筌浖_(kāi)發(fā)過(guò)程
普通的軟件開(kāi)發(fā)過(guò)程和面向?qū)ο箝_(kāi)發(fā)過(guò)程有著很大的不同?；叵胛覀?cè)诜敲嫦驅(qū)ο笾虚_(kāi)發(fā)過(guò)程中，最經(jīng)常采用的任務(wù)分配方法就是以軟件模塊為單位，這樣的好處是分配簡(jiǎn)單，不同任務(wù)之間耦合程度低，容易操作。壞處是幾乎無(wú)法做到重用，也缺乏整體性的設(shè)計(jì)。而面向?qū)ο筌浖_(kāi)發(fā)則不同，它是以類、類集合作為基本單位的。類之間關(guān)系錯(cuò)綜復(fù)雜（雖然我們提倡低耦合的設(shè)計(jì)，但類之間的關(guān)系仍然是相對(duì)復(fù)雜的）。這種情況下程序員之間相互協(xié)作的要求就非常之高，這種關(guān)系如果處理恰當(dāng)，則能夠完全體現(xiàn)出面向?qū)ο蟮耐?，否則，那將會(huì)是一場(chǎng)大災(zāi)難，面向?qū)ο蟮能浖_(kāi)發(fā)過(guò)程要養(yǎng)成一些好的習(xí)慣：盡量簡(jiǎn)化和穩(wěn)定客戶端。準(zhǔn)備一份簡(jiǎn)潔的文檔，并保持更新。盡可能多的考慮異常和錯(cuò)誤的情況。
?
C
基于面向?qū)ο蟠a的分析框架
在一個(gè)開(kāi)發(fā)過(guò)程中，往往有著多種復(fù)雜的因素：過(guò)程、技能、工具、規(guī)范、組織、個(gè)性。所有的這些，都會(huì)對(duì)最終的代碼產(chǎn)生影響，對(duì)代碼的成本和質(zhì)量產(chǎn)生影響。軟件最有價(jià)值的部分是代碼，根據(jù)敏捷方法和精益編程的思路，除了代碼之外的產(chǎn)出物，都不具有價(jià)值，或者說(shuō)對(duì)最終用戶沒(méi)有價(jià)值。但它們都需要成本的投入，而我們應(yīng)該考慮如何節(jié)省這些成本。
?
?
4
、應(yīng)用框架
框架不是框框—應(yīng)用框架的基本思想
軟件構(gòu)件化是
21
世紀(jì)軟件工業(yè)發(fā)展的大勢(shì)趨。工業(yè)化的軟件復(fù)用已經(jīng)從通用類庫(kù)進(jìn)化到了面向領(lǐng)域的應(yīng)用框架。
Gartner Group
認(rèn)為：“到
2003
年，至少
70%
的新應(yīng)用將主要建立在如軟件構(gòu)件和應(yīng)用框架這類‘構(gòu)造塊’之上；應(yīng)用開(kāi)發(fā)的未來(lái)就在于提供一開(kāi)放體系結(jié)構(gòu)，以方便構(gòu)件的選擇、組裝和集成”?？蚣艿闹赜靡殉蔀檐浖a(chǎn)中最有效的重用方式之一。
什么是框架？
框架（
Framework
）是整個(gè)或部分系統(tǒng)的可重用設(shè)計(jì)，表現(xiàn)為一組抽象構(gòu)件及構(gòu)件實(shí)例間交互的方法
;
另一種定義認(rèn)為，框架是可被應(yīng)用開(kāi)發(fā)者定制的應(yīng)用骨架。前者是從應(yīng)用方面而后者是從目的方面給出的定義。
可以說(shuō)，一個(gè)框架是一個(gè)可復(fù)用的設(shè)計(jì)構(gòu)件，它規(guī)定了應(yīng)用的體系結(jié)構(gòu)，闡明了整個(gè)設(shè)計(jì)、協(xié)作構(gòu)件之間的依賴關(guān)系、責(zé)任分配和控制流程，表現(xiàn)為一組抽象類以及其實(shí)例之間協(xié)作的方法，它為構(gòu)件復(fù)用提供了上下文
(Context)
關(guān)系。因此構(gòu)件庫(kù)的大規(guī)模重用也需要框架。
框架和設(shè)計(jì)模式
框架、設(shè)計(jì)模式這兩個(gè)概念總?cè)菀妆换煜?，其?shí)它們之間還是有區(qū)別的。構(gòu)件通常是代碼重用，而設(shè)計(jì)模式是設(shè)計(jì)重用，框架則介于兩者之間，部分代碼重用，部分設(shè)計(jì)重用，有時(shí)分析也可重用。在軟件生產(chǎn)中有三種級(jí)別的重用：內(nèi)部重用，即在同一應(yīng)用中能公共使用的抽象塊
;
代碼重用，即將通用模塊組合成庫(kù)或工具集，以便在多個(gè)應(yīng)用和領(lǐng)域都能使用；應(yīng)用框架的重用，即為專用領(lǐng)域提供通用的或現(xiàn)成的基礎(chǔ)結(jié)構(gòu)，以獲得最高級(jí)別的重用性。
為什么要進(jìn)行框架開(kāi)發(fā)
?
框架的最大好處就是重用。面向?qū)ο笙到y(tǒng)獲得的最大的復(fù)用方式就是框架，一個(gè)大的應(yīng)用系統(tǒng)往往可能由多層互相協(xié)作的框架組成。
由于框架能重用代碼，因此從一已有構(gòu)件庫(kù)中建立應(yīng)用變得非常容易，因?yàn)闃?gòu)件都采用框架統(tǒng)一定義的接口，從而使構(gòu)件間的通信簡(jiǎn)單。
框架能重用設(shè)計(jì)。它提供可重用的抽象算法及高層設(shè)計(jì)，并能將大系統(tǒng)分解成更小的構(gòu)件，而且能描述構(gòu)件間的內(nèi)部接口。這些標(biāo)準(zhǔn)接口使在已有的構(gòu)件基礎(chǔ)上通過(guò)組裝建立各種各樣的系統(tǒng)成為可能。只要符合接口定義，新的構(gòu)件就能插入框架中，構(gòu)件設(shè)計(jì)者就能重用構(gòu)架的設(shè)計(jì)。
框架還能重用分析。所有的人員若按照框架的思想來(lái)分析事務(wù)，那么就能將它劃分為同樣的構(gòu)件，采用相似的解決方法，從而使采用同一框架的分析人員之間能進(jìn)行溝通。
有利于在一個(gè)項(xiàng)目?jī)?nèi)多人協(xié)同工作；
大粒度的重用使得平均開(kāi)發(fā)費(fèi)用降低，開(kāi)發(fā)速度加快，開(kāi)發(fā)人員減少，維護(hù)費(fèi)用降低，而參數(shù)化框架使得適應(yīng)性、靈活性增強(qiáng)。
框架能使應(yīng)用程序的開(kāi)發(fā)簡(jiǎn)單，價(jià)格低廉，但是開(kāi)發(fā)框架不是一件容易的事。它是一個(gè)需要領(lǐng)域和設(shè)計(jì)經(jīng)驗(yàn)的反復(fù)過(guò)程。為了保證框架的靈活性，必須提取和發(fā)現(xiàn)熱點(diǎn)。設(shè)計(jì)模式可以簡(jiǎn)化這個(gè)過(guò)程，因?yàn)樗峁┝藢?duì)過(guò)去經(jīng)驗(yàn)的抽象。應(yīng)用框架能高度抽象同一領(lǐng)域內(nèi)的問(wèn)題，進(jìn)而降低開(kāi)發(fā)難度和強(qiáng)度。雖然框架和構(gòu)件技術(shù)已經(jīng)出現(xiàn)許多年了，開(kāi)始走入實(shí)用
,
但還不成熟，有大量問(wèn)題有待研究。
?
?
5
、模塊化和構(gòu)件化設(shè)計(jì)
?
?
?
6
、概要設(shè)計(jì)怎么做
在需求明確、準(zhǔn)備開(kāi)始編碼之前，要做概要設(shè)計(jì)，而詳細(xì)設(shè)計(jì)可能大部分公司沒(méi)有做，有做的也大部分是和編碼同步進(jìn)行，或者在編碼之后。因此，對(duì)大部分的公司來(lái)說(shuō)，概要設(shè)計(jì)文檔是唯一的設(shè)計(jì)文檔，對(duì)后面的開(kāi)發(fā)、測(cè)試、實(shí)施、維護(hù)工作起到關(guān)鍵性的影響。
大的系統(tǒng)的概要設(shè)計(jì)相當(dāng)于架構(gòu)設(shè)計(jì)和初步的系統(tǒng)設(shè)計(jì)。
?
概要設(shè)計(jì)的目的（架構(gòu)設(shè)計(jì)）
將軟件系統(tǒng)需求轉(zhuǎn)換為未來(lái)系統(tǒng)的設(shè)計(jì)；
逐步開(kāi)發(fā)強(qiáng)壯的系統(tǒng)構(gòu)架；
使設(shè)計(jì)適合于實(shí)施環(huán)境，為提高性能而進(jìn)行設(shè)計(jì)；
結(jié)構(gòu)應(yīng)該被分解為模塊和庫(kù)。
概要設(shè)計(jì)的任務(wù)
制定規(guī)范：代碼體系、接口規(guī)約、命名規(guī)則。這是項(xiàng)目小組今后共同作戰(zhàn)的基礎(chǔ)，有了開(kāi)發(fā)規(guī)范和程序模塊之間和項(xiàng)目成員彼此之間的接口規(guī)則、方式方法，大家就有了共同的工作語(yǔ)言、共同的工作平臺(tái)，使整個(gè)軟件開(kāi)發(fā)工作可以協(xié)調(diào)有序地進(jìn)行。
總體結(jié)構(gòu)設(shè)計(jì)：
?
功能（加工）－
>
模塊：每個(gè)功能用那些模塊實(shí)現(xiàn)，保證每個(gè)功能都有相應(yīng)的模塊來(lái)實(shí)現(xiàn)；
?
模塊層次結(jié)構(gòu)：某個(gè)角度的軟件框架視圖；
?
模塊間的調(diào)用關(guān)系：模塊間的接口的總體描述；
?
模塊間的接口：傳遞的信息及其結(jié)構(gòu)；
?
處理方式設(shè)計(jì)：滿足功能和性能的算法
?
用戶界面設(shè)計(jì)；
?
數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)：
?
詳細(xì)的數(shù)據(jù)結(jié)構(gòu)：表、索引、文件；
?
算法相關(guān)邏輯數(shù)據(jù)結(jié)構(gòu)及其操作；
?
上述操作的程序模塊說(shuō)明（在前臺(tái)？在后臺(tái)？用視圖？用過(guò)程？······）
?
接口控制表的數(shù)據(jù)結(jié)構(gòu)和使用規(guī)則
?
其他性能設(shè)計(jì)。
概要設(shè)計(jì)寫(xiě)什么
?
結(jié)構(gòu)化軟件設(shè)計(jì)說(shuō)明書(shū)結(jié)構(gòu)（因篇幅有限和過(guò)時(shí)嫌疑，在此不作過(guò)多解釋）
?
任務(wù)：目標(biāo)、環(huán)境、需求、局限；
?
總體設(shè)計(jì)：處理流程、總體結(jié)構(gòu)與模塊、功能與模塊的關(guān)系；
?
接口設(shè)計(jì)：總體說(shuō)明外部用戶、軟、硬件接口；內(nèi)部模塊間接口（注：接口≈系統(tǒng)界面）
?
數(shù)據(jù)結(jié)構(gòu)：邏輯結(jié)構(gòu)、物理結(jié)構(gòu)，與程序結(jié)構(gòu)的關(guān)系；
?
模塊設(shè)計(jì)：每個(gè)模塊“做什么”、簡(jiǎn)要說(shuō)明“怎么做”（輸入、輸出、處理邏輯、與其它模塊的接口，與其它系統(tǒng)或硬件的接口），處在什么邏輯位置、物理位置；
?
運(yùn)行設(shè)計(jì)：運(yùn)行模塊組合、控制、時(shí)間；
?
出錯(cuò)設(shè)計(jì)：出錯(cuò)信息、處錯(cuò)處理；
?
其他設(shè)計(jì)：保密、維護(hù)；
?
7
、代碼規(guī)范和注釋規(guī)范
?
?
?
8
、單元測(cè)試和測(cè)試案例
?
?
9
、團(tuán)隊(duì)協(xié)作及大中規(guī)模軟件開(kāi)發(fā)過(guò)程
大規(guī)模軟件需要團(tuán)隊(duì)合作開(kāi)發(fā)。
?
第一步：需求分析，產(chǎn)出
Use-Case
用例圖
第二步：概要設(shè)計(jì)，產(chǎn)出概要設(shè)計(jì)文檔（模塊設(shè)計(jì)和代碼規(guī)范等）
第三步：架構(gòu)設(shè)計(jì)，產(chǎn)出模塊化設(shè)計(jì)，功能設(shè)計(jì)，接口設(shè)計(jì)，模塊協(xié)作圖等圖及文檔
第四步：系統(tǒng)設(shè)計(jì)，產(chǎn)出
Sequence
序列圖，功能流程程圖
第五步：詳細(xì)設(shè)計(jì)，產(chǎn)出
Class
類圖，偽代碼設(shè)計(jì)，測(cè)試案例等
第六步：代碼開(kāi)發(fā)及單元測(cè)試
第七步：壓力測(cè)試和整體聯(lián)調(diào)測(cè)試
第八步：完成后續(xù)文檔和維護(hù)文檔等
?
?
?
10
、面向?qū)ο笤O(shè)計(jì)原則
The OpenThe Open--Closed PrincipleClosed Principle
任何系統(tǒng)在其生命周期中都會(huì)發(fā)生變化。如果我們希望開(kāi)發(fā)出的系統(tǒng)不會(huì)在第一版本后就被拋棄，那么我們就必須牢牢記住這一點(diǎn)。
軟件組成實(shí)體（類，模塊，函數(shù)，等等）應(yīng)該是可擴(kuò)展的，但是不可修改的。
?
OCP OCP
特征
1
、可擴(kuò)展（對(duì)擴(kuò)展是開(kāi)放的）
模塊的行為功能可以被擴(kuò)展，在應(yīng)用需求改變或需要滿足新的應(yīng)用需求時(shí)，我們可以讓模塊以不同的方式工作
2
、不可更改（對(duì)更改是封閉的）
這些模塊的源代碼是不可改動(dòng)的。任何人都不許修改模塊的源代碼。
?
關(guān)鍵是抽象！
模塊可以操作一個(gè)抽象體。由于模塊依賴于一個(gè)固定的抽象體，因此它可以是不允許修改（
closed for modification
）的；同時(shí)，通過(guò)從這個(gè)抽象體派生，也可擴(kuò)展此模塊的行為功能。
符合
OCP
原則的程序只通過(guò)增加代碼來(lái)變化而不是通過(guò)更改現(xiàn)有代碼來(lái)變化，因此這樣的程序就不會(huì)引起象非開(kāi)放―封閉（
open-closed
）的程序那樣的連鎖反應(yīng)的變化。
?
對(duì)可變性的封裝
考慮系統(tǒng)中什么可能會(huì)發(fā)生變化
一種可變性不應(yīng)當(dāng)散落在代碼的很多角落里，而應(yīng)當(dāng)被封裝到一個(gè)對(duì)象里
?
正確理解繼承
一種可變性不應(yīng)當(dāng)與另一個(gè)可變性混合在一起
?
選擇性的封閉（
Strategic Closure
）沒(méi)有任何一個(gè)大的程序能夠做到
100%
的封閉。一般來(lái)講，無(wú)論模塊是多么的“封閉”，都會(huì)存在一些無(wú)法對(duì)之封閉的變化。既然不可能完全封閉，因此就必須選擇性地對(duì)待這個(gè)問(wèn)題。也就是說(shuō)，設(shè)計(jì)者必須對(duì)于他（她）設(shè)計(jì)的模塊應(yīng)該對(duì)何種變化封閉做出選擇。
?
?
Liskov
替換原則替換原則
LSP The The Liskov Substitution Principle
OCP
原則背后的主要機(jī)制是抽象和多態(tài)。支持抽象和多態(tài)的關(guān)鍵機(jī)制是繼承。
?
LSP
的定義
若對(duì)于每一個(gè)類型
S
的對(duì)象
o1
，都存在一個(gè)類型
T
的對(duì)象
o2
，使得在所有針對(duì)
T
編寫(xiě)的程序
P
中，用
o1
替換
o2
后，程序
P
的行為功能不變，則
S
是
T
的子類型。
LSP
原則清楚地指出，
OOD
中
Is-A
關(guān)系是就行為功能而言。行為功能（
behavior
）不是內(nèi)在的、私有的，而是外在、公開(kāi)的，是客戶程序所依賴的。行為功能（
behavior
）才是軟件所關(guān)注的問(wèn)題！所有派生類的行為功能必須和客戶程序?qū)ζ浠愃谕谋３忠恢隆?/span>
?
LSP
和
DBC
DBC
（
Design by Contract
）定義把類和其客戶之間的關(guān)系看作是一個(gè)正式的協(xié)議，明確各方的權(quán)利和義務(wù)。
DBC
對(duì)類的要求類的方法聲明為先決條件（
precondition
）和后續(xù)條件（
postcondition
）。為了讓方法得以執(zhí)行，先決條件必須為真。完成后，方法保證后續(xù)條件為真。
DBC
對(duì)派生類的要求當(dāng)重新定義派生類中的例行程序時(shí)，我們只能用更弱的先決條件和更強(qiáng)的后續(xù)條件替換之。
?
LSP
－結(jié)論
LSP
原則是符合
OCP
原則應(yīng)用程序的一項(xiàng)重要特性。僅當(dāng)派生類能完全替換基類時(shí)，我們才能放心地重用那些使用基類的函數(shù)和修改派生類型。
高層模塊不應(yīng)該依賴于低層模塊。二者都應(yīng)該依賴于抽象。
抽象不應(yīng)該依賴于細(xì)節(jié)。細(xì)節(jié)應(yīng)該依賴于抽象。
實(shí)施重點(diǎn)
從問(wèn)題的具體細(xì)節(jié)中分離出抽象，以抽象方式對(duì)類進(jìn)行耦合
不足
導(dǎo)致生成大量的類
假定所有的具體類都是會(huì)變化的，這也不總是正確的
DIP
與設(shè)計(jì)模式
DIP
以
LSP
為基礎(chǔ)，是實(shí)現(xiàn)
OCP
的主要手段，是設(shè)計(jì)模式研究和應(yīng)用的主要指導(dǎo)原則
接口隔離原則（
ISP
）恰當(dāng)?shù)膭澐纸巧徒涌?/font>
接口的污染（
Interface Contamination
）一個(gè)沒(méi)有經(jīng)驗(yàn)的設(shè)計(jì)師往往想節(jié)省接口的數(shù)目，將一些功能相近或功能相關(guān)的接口合并，并將這看成是代碼優(yōu)化的一部分。
定義：從一個(gè)客戶類的角度來(lái)講：一個(gè)類對(duì)另外一個(gè)類的依賴性應(yīng)當(dāng)是建立在最小的接口上的。使用多個(gè)專門(mén)的接口比使用單一的總接口要好。
合成
/
聚合復(fù)用原則（
CARP
）盡量使用合成
/
聚合、盡量不使用繼承
定義：在一個(gè)新的對(duì)象里面使用一些已有的對(duì)象，使之成為新對(duì)象的一部分；新的對(duì)象通過(guò)向這些對(duì)象的委派達(dá)到復(fù)用這些對(duì)象的目的。
?
?
11
、設(shè)計(jì)模式
在面向?qū)ο蟮木幊讨?，軟件編程人員更加注重以前的代碼的重用性和可維護(hù)性。
設(shè)計(jì)模式使人們可以更加簡(jiǎn)單方便地復(fù)用成功的設(shè)計(jì)和體系結(jié)構(gòu)。將已證實(shí)的技術(shù)表述成設(shè)計(jì)模式也會(huì)使新系統(tǒng)開(kāi)發(fā)者更加容易理解其設(shè)計(jì)思路。
?
一般而言，一個(gè)模式有四個(gè)基本要素
1.
模式名稱（
pattern name
）
一個(gè)助記名，它用一兩個(gè)詞來(lái)描述模式的問(wèn)題、解決方案和效果。命名一個(gè)新的模式增加了我們的設(shè)計(jì)詞匯。設(shè)計(jì)模式允許我們?cè)谳^高的抽象層次上進(jìn)行設(shè)計(jì)?；谝粋€(gè)模式詞匯表，我們自己以及同事之間就可以討論模式并在編寫(xiě)文檔時(shí)使用它們。模式名可以幫助我們思考，便于我們與其他人交流設(shè)計(jì)思想及設(shè)計(jì)結(jié)果。找到恰當(dāng)?shù)哪Ｊ矫彩俏覀冊(cè)O(shè)計(jì)模式編目工作的難點(diǎn)之一。
2.
問(wèn)題
(problem)
描述了應(yīng)該在何時(shí)使用模式。它解釋了設(shè)計(jì)問(wèn)題和問(wèn)題存在的前因后果，它可能描述了特定的設(shè)計(jì)問(wèn)題，如怎樣用對(duì)象表示算法等。也可能描述了導(dǎo)致不靈活設(shè)計(jì)的類或?qū)ο蠼Y(jié)構(gòu)。有時(shí)候，問(wèn)題部分會(huì)包括使用模式必須滿足的一系列先決條件。
3.
解決方案
(solution)
描述了設(shè)計(jì)的組成成分，它們之間的相互關(guān)系及各自的職責(zé)和協(xié)作方式。因?yàn)槟Ｊ骄拖褚粋€(gè)模板，可應(yīng)用于多種不同場(chǎng)合，所以解決方案并不描述一個(gè)特定而具體的設(shè)計(jì)或?qū)崿F(xiàn)，而是提供設(shè)計(jì)問(wèn)題的抽象描述和怎樣用一個(gè)具有一般意義的元素組合（類或?qū)ο蠼M合）來(lái)解決這個(gè)問(wèn)題。
4.
效果
(consequences)
描述了模式應(yīng)用的效果及使用模式應(yīng)權(quán)衡的問(wèn)題。盡管我們描述設(shè)計(jì)決策時(shí)，并不總提到模式效果，但它們對(duì)于評(píng)價(jià)設(shè)計(jì)選擇和理解使用模式的代價(jià)及好處具有重要意義。軟件效果大多關(guān)注對(duì)時(shí)間和空間的衡量，它們也表述了語(yǔ)言和實(shí)現(xiàn)問(wèn)題。因?yàn)閺?fù)用是面向?qū)ο笤O(shè)計(jì)的要素之一，所以模式效果包括它對(duì)系統(tǒng)的靈活性、擴(kuò)充性或可移植性的影響，顯式地列出這些效果對(duì)理解和評(píng)價(jià)這些模式很有幫助。
?
一些基本的設(shè)計(jì)模式
Abstract Factory
：提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無(wú)需指定它們具體的類。
Adapter
：將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口。
A d a p t e r
模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
Bridge
：將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。
Builder
：將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。
Chain of Responsibility
：為解除請(qǐng)求的發(fā)送者和接收者之間耦合，而使多個(gè)對(duì)象都有機(jī)會(huì)處理這個(gè)請(qǐng)求。將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞該請(qǐng)求，直到有一個(gè)對(duì)象處理它。
Command
：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可取消的操作。
Composite
：將對(duì)象組合成樹(shù)形結(jié)構(gòu)以表示“部分
-
整體”的層次結(jié)構(gòu)。它使得客戶對(duì)單個(gè)對(duì)象和復(fù)合對(duì)象的使用具有一致性。
Decorator
：動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。就擴(kuò)展功能而言，
它比生成子類方式更為靈活。
Facade
：為子系統(tǒng)中的一組接口提供一個(gè)一致的界面，
F a c a d e
模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。
Factory Method
：定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定將哪一個(gè)類實(shí)例化。
Factory Method
使一個(gè)類的實(shí)例化延遲到其子類。
Flyweight
：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象。
Interpreter
：給定一個(gè)語(yǔ)言
,
定義它的文法的一種表示，并定義一個(gè)解釋器
,
該解釋器使用該表示來(lái)解釋語(yǔ)言中的句子。
Iterator
：提供一種方法順序訪問(wèn)一個(gè)聚合對(duì)象中各個(gè)元素
,
而又不需暴露該對(duì)象的內(nèi)部表示。
Mediator
：用一個(gè)中介對(duì)象來(lái)封裝一系列的對(duì)象交互。中介者使各對(duì)象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。
Memento
：在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣以后就可將該對(duì)象恢復(fù)到保存的狀態(tài)。
Observer
：定義對(duì)象間的一種一對(duì)多的依賴關(guān)系
,
以便當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)
,
所有依賴于它的對(duì)象都得到通知并自動(dòng)刷新。
Prototype
：用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并且通過(guò)拷貝這個(gè)原型來(lái)創(chuàng)建新的對(duì)象。
Proxy
：為其他對(duì)象提供一個(gè)代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn)。
Singleton
：保證一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問(wèn)它的全局訪問(wèn)點(diǎn)。
State
：允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變它的行為。對(duì)象看起來(lái)似乎修改了它所屬的類。
Strategy
：定義一系列的算法
,
把它們一個(gè)個(gè)封裝起來(lái)
,
并且使它們可相互替換。本模式使得算法的變化可獨(dú)立于使用它的客戶。
Template Method
：定義一個(gè)操作中的算法的骨架，而將一些步驟延遲到子類中。
Template Method
使得子類可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。
Visitor
：表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。
?
?
12
、經(jīng)驗(yàn)談
1
、不迷信于某篇文章或某人或某一個(gè)理論，理解和領(lǐng)悟勝于死搬硬套，靈活運(yùn)用
2
、用抽象的思維代替程序化的思維，找出事物的共性，分離出抽象的接口，可以不變應(yīng)萬(wàn)變，適應(yīng)不同的需求。
3
、用對(duì)象代替數(shù)據(jù)，用成員方法代替函數(shù)來(lái)思考問(wèn)題，設(shè)計(jì)系統(tǒng)。
4
、代碼要規(guī)范，注釋要規(guī)范。比如頭文件的包含關(guān)系，類型定義、聲明和實(shí)現(xiàn)的位置等，都需要有規(guī)范的統(tǒng)一。
5
、學(xué)會(huì)拿來(lái)主義，從別的優(yōu)秀的系統(tǒng)中吸取自己想要的東西，而不是自己照搬照抄或者全部從零構(gòu)建系統(tǒng)。
6
、框架是代碼的復(fù)用，設(shè)計(jì)模式是設(shè)計(jì)的復(fù)用，面向?qū)ο笫窃O(shè)計(jì)的方法，
UML
是設(shè)計(jì)的工具，
RUP
是軟件開(kāi)發(fā)的過(guò)程。
?
?
?
?
作者：naven? 2005-5-10
參考文獻(xiàn)：
1
、
www.uml.org.cn
、
2
、《
UML
：
Java
程序員指南》
?