大話設(shè)計(jì)模式總結(jié)_第1頁
大話設(shè)計(jì)模式總結(jié)_第2頁
大話設(shè)計(jì)模式總結(jié)_第3頁
大話設(shè)計(jì)模式總結(jié)_第4頁
大話設(shè)計(jì)模式總結(jié)_第5頁
已閱讀5頁,還剩30頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1、UML類圖 在UML類圖中,常見的有以下幾種關(guān)系: 泛化(Generalization),  實(shí)現(xiàn)(Realization),關(guān)聯(lián)(Association),聚合(Aggregation),組合(Composition),依賴(Dependency)。1. 泛化(Generalization)【泛化關(guān)系】是一種繼承關(guān)系,表示一般與特殊的關(guān)系,它指定了子類如何特化父類的所有特征和行為。例如:老虎是動物的一種,即有老虎的特性也有動物的共性。【箭頭及指向】帶三角箭頭的實(shí)線,箭頭指向父類。 泛化 實(shí)現(xiàn)2. 實(shí)現(xiàn)(Realization)【實(shí)現(xiàn)

2、關(guān)系】是一種類與接口的關(guān)系,表示類是接口所有特征和行為的實(shí)現(xiàn)。【箭頭及指向】帶三角箭頭的虛線,箭頭指向接口。3. 關(guān)聯(lián)(Association)【關(guān)聯(lián)關(guān)系】是一種擁有的關(guān)系,它使一個類知道另一個類的屬性和方法;如:老師與學(xué)生,丈夫與妻子關(guān)聯(lián)可以是雙向的,也可以是單向的。雙向的關(guān)聯(lián)可以有兩個箭頭或者沒有箭頭,單向的關(guān)聯(lián)有一個箭頭。【代碼體現(xiàn)】成員變量【箭頭及指向】帶普通箭頭的實(shí)心線,指向被擁有者上圖中,老師與學(xué)生是雙向關(guān)聯(lián),老師有多名學(xué)生,學(xué)生也可能有多名老師。但學(xué)生與某課程間的關(guān)系為單向關(guān)聯(lián),一名學(xué)生可能要上多門課程,課程是個抽象的東西他不擁有學(xué)生。 下圖為自身關(guān)聯(lián):

3、60; 4. 聚合(Aggregation)【聚合關(guān)系】是整體與部分的關(guān)系,且部分可以離開整體而單獨(dú)存在。如車和輪胎是整體和部分的關(guān)系,輪胎離開車仍然可以存在。聚合關(guān)系是關(guān)聯(lián)關(guān)系的一種,是強(qiáng)的關(guān)聯(lián)關(guān)系;關(guān)聯(lián)和聚合在語法上無法區(qū)分,必須考察具體的邏輯關(guān)系。【代碼體現(xiàn)】成員變量【箭頭及指向】帶空心菱形的實(shí)心線,菱形指向整體 聚合 組合5. 組合(Composition)【組合關(guān)系】是整體與部分的關(guān)系,但部分不能離開整體而單獨(dú)存在。如公司和部門是整體和部分的關(guān)系,沒有公司就不存在部門。組合關(guān)系是關(guān)聯(lián)關(guān)系的一種,是比聚合關(guān)系還要強(qiáng)的關(guān)系,它要求普通的聚合關(guān)系中代表整體的對

4、象負(fù)責(zé)代表部分的對象的生命周期。【代碼體現(xiàn)】成員變量【箭頭及指向】帶實(shí)心菱形的實(shí)線,菱形指向整體  6. 依賴(Dependency)【依賴關(guān)系】是一種使用的關(guān)系,即一個類的實(shí)現(xiàn)需要另一個類的協(xié)助,所以要盡量不使用雙向的互相依賴.【代碼表現(xiàn)】局部變量、方法的參數(shù)或者對靜態(tài)方法的調(diào)用【箭頭及指向】帶箭頭的虛線,指向被使用者各種關(guān)系的強(qiáng)弱順序:泛化 = 實(shí)現(xiàn) > 組合 > 聚合 > 關(guān)聯(lián) > 依賴 下面這張UML圖,比較形象地展示了各種

5、類圖關(guān)系:參考資料:設(shè)計(jì)模式之重要原則1. 單一職責(zé)原則(SRP)就一個類而言,應(yīng)該僅有一個引起它變化的原因。如果一個類承擔(dān)的職責(zé)過多,就等于把這些職責(zé)耦合在一起,一個職責(zé)的變化變化可能會削弱或抑制這個類完成其它職責(zé)的能力。這種耦合會導(dǎo)致脆弱的設(shè)計(jì),當(dāng)變化發(fā)生時,設(shè)計(jì)會遭到意想不到的破壞。軟件設(shè)計(jì)真正要做的許多內(nèi)容,就是發(fā)現(xiàn)職責(zé)并把那些職責(zé)相互分離。2. 開放-封閉原則是說軟件實(shí)體(類、模塊、函數(shù)等)應(yīng)該可以擴(kuò)展,但是不可修改。也就說,對于擴(kuò)展是開放的(Open for extension),對于更改是封閉的(Closed for modification).無論模塊是多么的“封閉”,都會存在

6、一些無法對之封閉的變化。既然不可能完全封閉,設(shè)計(jì)人員必須對于他設(shè)計(jì)的模塊應(yīng)該對哪種變化封閉做出選擇。他必須先猜測出最具有可能發(fā)生的變化種類,然后構(gòu)造抽象來隔離那些變化。等到變化發(fā)生時立即采取行動。在我們最初編寫代碼時,假設(shè)變化不會發(fā)生。當(dāng)變化發(fā)生時,我們就創(chuàng)建抽象來隔離以后發(fā)生的同類變化。面對需求,對程序的改動是通過增加新代碼進(jìn)行的,而不是更改現(xiàn)有的代碼。開放-封閉原則是面向?qū)ο笤O(shè)計(jì)的核心所在。遵循這個原則可以帶來面向?qū)ο蠹夹g(shù)所聲稱的巨大好處,也就是可維護(hù)、可擴(kuò)展、可復(fù)用、靈活性好。開發(fā)人員應(yīng)該僅對程序中呈現(xiàn)出頻繁變化的那部分做出抽象,然而,對于應(yīng)用程序中的每個部分都刻意地進(jìn)行抽象同樣不是一個

7、好主意。拒絕不成熟的抽象和抽象本身一樣重要。3. 依賴倒轉(zhuǎn)原則A 高層模塊不應(yīng)該依賴低層模塊。兩個都應(yīng)該依賴抽象。B 抽象不應(yīng)該依賴細(xì)節(jié)。細(xì)節(jié)應(yīng)該依賴抽象。4. 里氏代換原則子類型必須能夠替換掉它們的父類型。一個軟件實(shí)體如果使用的是一個父類的話,那么一定適用于其子類,而且察覺不出父類對象和子類對象的區(qū)別。也就是說,在軟件里面,把父類都替換成它的子類,程序的行為沒有變化。5. 迪米特法則(最少知識原則) 如果兩個類不必彼此直接通信,那么這兩個類就不應(yīng)當(dāng)發(fā)生直接的相互作用。如果其中一個類需要調(diào)用另一個類的某一個方法的話,可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用。 迪米特法則根本思想,是強(qiáng)調(diào)類之間的松耦合。類之間

8、的耦合越弱,越有利于復(fù)用,一個處在弱耦合的類被修改,不會對有關(guān)系的類造成波及。6. 合成、聚合復(fù)用原則 盡量使用合成/聚合,盡量不要使用類繼承。優(yōu)先使用對象的合成/聚合將有助于你保持每個類被封裝,并被集中在單個任務(wù)上。這樣類和類繼承層次會保持較小規(guī)模,并且不太可能增長為不可控制的龐然大物。7. 敏捷開發(fā)原則 不要為代碼添加基于猜測的、實(shí)際不需要的功能。 設(shè)計(jì)模式1:策略模式(Strategy)策略模式:它定義了算法家族,分別封裝起來,讓它們之間可以互相替換。此模式讓算法的變化,不會影響到使用算法的客戶。優(yōu)點(diǎn):策略模式的Strategy類層次為Context定義了一系列的可供重用的算法或行為。繼

9、承有助于析取出這些算法中的公共功能。簡化了單元測試,因?yàn)槊總€算法都有自己的類,可以通過自己的接口單獨(dú)測試。適用情形:策略模式就是用來封裝算法的,但在實(shí)踐中,我們可以發(fā)現(xiàn)可以用它封裝任何類型的規(guī)則,只要在分析過程中聽到需要在不同時間應(yīng)用不同的業(yè)務(wù)規(guī)則,就可以考慮使用策略模式處理這種變化的可能性。設(shè)計(jì)模式2:裝飾模式(Decorator)裝飾模式:動態(tài)地給對象添加一些額外的職責(zé),就增加功能來說,裝飾模式比生成子類更為靈活。裝飾模式提供了一個非常好的解決方案,它把每個要裝飾的功能放在單獨(dú)的類中,并讓這個類包裝它所要裝飾的對象,因此,當(dāng)需要執(zhí)行特殊行為時,客戶端代碼就可以在運(yùn)行時根據(jù)需要有選擇地、按順

10、序地使用裝飾功能包裝對象了。優(yōu)點(diǎn):把類的裝飾功能從類中搬移去除,這樣可以簡化原有的類;有效地把類的核心職能和裝飾職能區(qū)分開了,可以去除相關(guān)類中重復(fù)的裝飾邏輯。設(shè)計(jì)模式3:代理模式(Proxy)代理模式:為其它對象提供一種代理以控制對該對象的訪問。使用情形:(1)遠(yuǎn)程代理,也就是為一個對象在不同的地址空間提供局部代表。這樣可以隱藏一個對象存在于不同地址空間的事實(shí)。(2)虛擬代理,是根據(jù)需要創(chuàng)建開銷很大的對象。通過它來存放實(shí)例化需要很長時間的真實(shí)對象。(3)安全代理,用來控制真實(shí)對象訪問時的權(quán)限。(4)智能指引,是指當(dāng)調(diào)用真實(shí)的對象時,代理處理另外一些事。設(shè)計(jì)模式4:工廠方法模式(Factory

11、Method)工廠方法模式:定義一個用于創(chuàng)建對象的接口,讓子類決定實(shí)例化哪一個類。工廠方法使一個類的實(shí)例化延遲到其子類。與簡單工廠模式相比,沒有違反開放-擴(kuò)展原則,把簡單工廠內(nèi)部的邏輯判斷移到了客戶端。簡單工廠模式的最大優(yōu)點(diǎn)是工廠類中包含了必要的邏輯判斷,根據(jù)客戶端的選擇條件動態(tài)地實(shí)例化相關(guān)的類,對于客戶端來說,去除了與具體產(chǎn)品的依賴。工廠方法模式實(shí)現(xiàn)時,客戶端需要決定實(shí)例化哪一個工廠類來實(shí)現(xiàn)運(yùn)算類,選擇判斷的問題還是存在的,也就是說,工廠方法把簡單工廠的內(nèi)部邏輯判斷移到了客戶端代碼來進(jìn)行。你想要加功能,本來是改工廠類的,而現(xiàn)在是修改客戶端。設(shè)計(jì)模式5:原型模式(Prototype)原型模式:

12、用原型實(shí)例指定創(chuàng)建對象的種類,并且通過拷貝這些原型創(chuàng)建新的對象(不需要知道任何創(chuàng)建的細(xì)節(jié))。原型模式其實(shí)就是從一個對象再創(chuàng)建另外一個可定制對象,而且不需要知道任何創(chuàng)建的細(xì)節(jié)。“淺復(fù)制”被復(fù)制的對象的所有變量都含有與原來的對象相同的值,而所有的對其他對象的引用都仍然指向原來的對象。“深復(fù)制”把引用對象的變量指向復(fù)制過的新對象,而不是原有的被引用的對象。設(shè)計(jì)模式6:模板方法模式(Template Method)模板方法模式:定義一個操作中的算法的骨架,而將一些步驟延遲到了子類中。模板方法使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。特點(diǎn):模板方法模式通過把不變的行為搬移到超類,去

13、除子類中重復(fù)代碼來體現(xiàn)它的優(yōu)勢。模板方法模式提供了一個很好的代碼復(fù)用平臺。適用情形:當(dāng)不變的和可變的行為在方法的子類實(shí)現(xiàn)中混合在一起的時候,不變的行為就會在子類中重復(fù)出現(xiàn)。通過模板方法模式把這些行為搬移到單一的地方,這樣就幫子類擺脫重復(fù)的不變行為的糾纏。設(shè)計(jì)模式7:外觀模式(Facade)外觀模式:為子系統(tǒng)的一組接口提供一個一致的界面,此模式定義了一個高層接口,這個接口使得這一子系統(tǒng)更加容易使用。在軟件開發(fā)中使用情形:(1)設(shè)計(jì)階段,應(yīng)該有意識地將不同的兩個層分離,比如經(jīng)典的三層架構(gòu),就需要考慮在數(shù)據(jù)訪問層和業(yè)務(wù)邏輯層、業(yè)務(wù)邏輯層和表示層的層與層之間建立外觀Façade,這樣可以為復(fù)

14、雜子系統(tǒng)提供一個簡單的接口,使耦合度大大降低。(2)開發(fā)階段,子系統(tǒng)往往因?yàn)椴粩嗟刂貥?gòu)演化而變得越來越復(fù)雜,產(chǎn)生很多很小的類,增加外觀Façade可以提供一個簡單的接口,減少它們之間的依賴。(3)維護(hù)階段,在維護(hù)一個遺留的大型系統(tǒng)時,可能這個系統(tǒng)已經(jīng)非常難以維護(hù)和擴(kuò)展了,但因?yàn)槠浒浅V匾墓δ埽碌男枨箝_發(fā)必須要依賴它。此時為新系統(tǒng)開發(fā)一個外觀類,來提供設(shè)計(jì)粗糙或高度復(fù)雜的遺留代碼的比較清晰簡單的接口,讓新系統(tǒng)與Façade對象交互,F(xiàn)açade與遺留代碼交互所有復(fù)雜的工作。設(shè)計(jì)模式8:建造者模式(Builder)建造者模式:將一個復(fù)雜對象的構(gòu)建與它的表示分離

15、,使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。適用情形:主要用于創(chuàng)建一些復(fù)雜的對象,這些對象內(nèi)部構(gòu)建間的建造順序通常是穩(wěn)定的,但對象內(nèi)部的構(gòu)建通常面臨這復(fù)雜的變化。優(yōu)點(diǎn):建造者模式使得建造代碼與表示代碼分離,由于建造者隱藏了該產(chǎn)品是如何組裝的,所以若需要改變一個產(chǎn)品的內(nèi)部表示,只需要再定義一個具體的建造者就可以了。設(shè)計(jì)模式9:觀察者模式(Observer)觀察者模式:觀察者模式:定義了一種一對多的依賴關(guān)系,讓多個觀察者對象同時監(jiān)聽某一個主題。這個主題對象在狀態(tài)發(fā)生變化時,會通知所有觀察者對象,使它們能夠自動更新自己。適用情形:當(dāng)一個對象的改變需要同時改變其他對象的時候,而且不知道具體有多少對象有待改

16、變時,應(yīng)考慮使用觀察者模式;一個抽象模型有兩個方面,其中一方面依賴于另一方方面,這時用觀察者模式可以將兩者封裝在獨(dú)立的對象中使它們各自獨(dú)立的改變和復(fù)用。設(shè)計(jì)模式10:抽象工廠模式(Abstract Factory)抽象工廠模式:提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口,而無需指定它們具體的類。優(yōu)點(diǎn)(1):易于交換產(chǎn)品系列,由于具體工廠類,例如IFactory factory = newAccessFactory(),在一個應(yīng)用中只需要在初始化時候出現(xiàn)一次,這就使得改變一個應(yīng)用的具體工廠變得非常容易,它只需要改變具體工廠即可使用不同的產(chǎn)品配置。(2)它讓具體的創(chuàng)建實(shí)例過程與客戶端分離,客戶端是

17、通過它們的抽象接口操縱實(shí)例,產(chǎn)品的具體類名也被具體的工廠分離,不會出現(xiàn)在代碼中。設(shè)計(jì)模式11:狀態(tài)模式(State)狀態(tài)模式:當(dāng)一個對象的內(nèi)部狀態(tài)改變時允許改變其行為,這個對象看起來像改變了其類。狀態(tài)模式主要解決的是當(dāng)控制一個對象狀態(tài)轉(zhuǎn)換的條件表達(dá)式過于復(fù)雜時的情況。把狀態(tài)的判斷邏輯轉(zhuǎn)移到表示不同狀態(tài)的一系列類當(dāng)中,可以把復(fù)雜的邏輯簡化。當(dāng)一個對象的行為取決于它的狀態(tài),并且它必須在運(yùn)行時刻根據(jù)狀態(tài)改變它的行為時,就可以考慮使用狀態(tài)模式。好處:將與特定狀態(tài)相關(guān)的行為局部化,并且將不同狀態(tài)的行為分割開來。也就是說,將特定的狀態(tài)相關(guān)的行為都放入一個對象中,由于所有與狀態(tài)相關(guān)的代碼都存在于某個Conc

18、reteState中,所以通過定義新的子類可以很容易地增加新的狀態(tài)和轉(zhuǎn)換。狀態(tài)模式通過吧各種狀態(tài)轉(zhuǎn)移邏輯分布到State的子類之間,來減少相互之間的依賴。設(shè)計(jì)模式12:適配器模式(Adapter)適配器模式:將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。在軟件開發(fā)中,系統(tǒng)的數(shù)據(jù)和行為都正確,但接口不符時,我們應(yīng)該考慮用適配器,目的是使控制范圍之外的一個原有對象與某個接口匹配。適配器模式主要用于希望復(fù)用一些現(xiàn)存的類,但是接口又與復(fù)用環(huán)境要求不一致的情況。兩個類所做的事情相同或相似,但是具有不同的接口時使用它。設(shè)計(jì)模式13:

19、備忘錄模式(Memento)備忘錄模式:在不破壞封裝性的前提下,捕獲一個對象的內(nèi)部狀態(tài),并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復(fù)到原先保存的狀態(tài)。適用場合:Memento模式比較適用于功能比較復(fù)雜的,但需要維護(hù)或記錄屬性歷史的類,或者需要保存的屬性只是眾多屬性中的一部分時,Originator可以根據(jù)保存的Memento信息還原到前一狀態(tài)。如果在某個系統(tǒng)中使用命令模式時,需要實(shí)現(xiàn)命令的撤銷功能,那么命令模式可以使用備忘錄模式來存儲可撤銷操作的狀態(tài)。使用備忘錄可以把復(fù)雜的對象內(nèi)部信息對其他的對象屏蔽起來。設(shè)計(jì)模式14:組合模式(Composite)組合模式:將對象組合成樹形結(jié)構(gòu)以表示

20、部分-整體的層次結(jié)構(gòu)。組合模式使得用戶對單個對象和組合對象的使用具有一致性。適用場合:需求中是體現(xiàn)部分與整體層次的結(jié)構(gòu)時,以及你希望用戶可以忽略組合對象與單個對象的不同,統(tǒng)一的使用組合結(jié)構(gòu)中所有對象時,就應(yīng)該考慮使用組合模式了。組合模式根據(jù)組合部件Component聲明接口的方式,又可分為透明方式和安全方式。透明方式:Component中聲明所有用來管理子對象的方法,其中包括Add、Remove等。這樣實(shí)現(xiàn)Component接口的所有子對象都具備了Add和Remove。這樣做的好處葉節(jié)點(diǎn)和枝節(jié)點(diǎn)對于外界沒有區(qū)別,它們具備完全一致的行為接口。但問題也很明顯,因?yàn)長eaf類本身不具備Add()、R

21、emove()方法的功能,所以實(shí)現(xiàn)它沒有意義。安全方式:在Component接口中不去聲明Add和Remove方法,那么子類的Leaf也就不需要去實(shí)現(xiàn)它,而是在Composite聲明所有用來管理子類對象的的方法,這樣做的就不會出現(xiàn)剛才提到的問題,不過由于不夠透明,所以樹葉和樹枝類將具備不同的接口,客戶端的調(diào)用需要做相應(yīng)的判斷,帶來了不便。設(shè)計(jì)模式15:迭代器模式(Iterator)迭代器模式:提供一種方法順序訪問一個聚合對象中的各個元素,而又不暴露該對象的內(nèi)部表示。適用場合:當(dāng)你需要訪問一個聚集對象,而且不管這些對象是什么都需要遍歷的時候,你就應(yīng)該考慮用迭代器模式。你需要對聚集有多種方式遍歷時

22、,可以考慮用迭代器模式。設(shè)計(jì)模式16:單例模式(Singleton)單例模式:保證一個類僅有一個實(shí)例,并提供一個訪問它的全局點(diǎn)。通常我們可以讓一個全局變量使得一個對象被訪問,但它不能防止你實(shí)例化多個對象。一個最好的辦法就是,讓類自身負(fù)責(zé)保存它的唯一實(shí)例。這個類可以保證沒有其它實(shí)例可以被創(chuàng)建,并且它可以提供一個訪問該實(shí)例的方法。設(shè)計(jì)模式17:橋接模式(Bridge)橋接模式:將抽象部分與它的實(shí)現(xiàn)部分分離,使它們都可以獨(dú)立地變化。抽象與它的實(shí)現(xiàn)分離并不是指抽象類與其派生類分離,因?yàn)檫@沒有任何意義。實(shí)現(xiàn)指的是抽象類和它的派生類用來實(shí)現(xiàn)自己的對象。通俗地講,實(shí)現(xiàn)系統(tǒng)可能有多角度分類,每一種分類都可能變

23、化,那么就把這種多角度分離出來讓它們獨(dú)立變化,減少它們之間的耦合。設(shè)計(jì)模式18:命令模式(Command)命令模式:將一個請求封裝為一個對象,從而使你可用不同地請求對客戶進(jìn)行參數(shù)化;對請求排隊(duì)或記錄請求日志,以支持可撤銷操作。優(yōu)點(diǎn):1)它能較容易設(shè)計(jì)一個命令隊(duì)列;2)在需要的情況下,可以較容易地將命令記入日志;3)允許接收請求的一方?jīng)Q定是否要否決請求;4)可以容易地實(shí)現(xiàn)對請求的撤銷和重做;5)由于加進(jìn)新的具體命令類不影響其它的類,因此增加新的具體命令類很容易。6)命令模式把請求一個操作的對象與知道怎么執(zhí)行一個操作的對象分隔開。設(shè)計(jì)模式19:職責(zé)鏈模式(Chain of Responsibili

24、ty)職責(zé)鏈模式:使得多個對象都有機(jī)會處理請求,從而避免請求的發(fā)送者和接收者之間的耦合。將這個對象連成一條鏈,并沿著這條鏈傳遞該請求,直到有一個對象處理它。優(yōu)點(diǎn):當(dāng)客戶提交一個請求時,請求是沿鏈傳遞直至有一個ConcreteHandler處理它。接收者和發(fā)送者都沒有對方的明確信息,且鏈中的對象自己也并不知道鏈的結(jié)構(gòu)。結(jié)果是職責(zé)鏈可簡化對象的相互連接,它們僅需保持一個指向其后繼者的引用,而不需保持它所有的候選接受者的引用。由于是在客戶端來定義鏈的結(jié)構(gòu),可以隨時地增加或修改處理一個請求的結(jié)構(gòu)。增強(qiáng)了給對象指派職責(zé)的靈活性。一個請求極有可能到了鏈的末端都得不到處理,或者因?yàn)闆]有正確配置而得不到處理。設(shè)計(jì)模式20:中介者模式(Mediator)中介者模式:用一個中介對象來封裝一系列的對象交互。中介者對象使各對象不需要顯示地相互交互,從而使其耦合松散,而且可以獨(dú)立地改變它們之間的交互。設(shè)計(jì)模式21:享元模式(Mediator)享元模式:運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對象。內(nèi)部狀態(tài)與外部狀態(tài):在享元對象內(nèi)部并且不會隨環(huán)境改變而改變的共享部分,稱為享元對象的內(nèi)部狀態(tài);而隨環(huán)境改變而改變的、不可共享的狀態(tài)稱為外部狀態(tài)。享元模式可以避免大量非常相似的開銷。在程序設(shè)計(jì)中,有時需要生成大量細(xì)粒度的類實(shí)例來表示數(shù)據(jù)。如果能發(fā)現(xiàn)這些實(shí)例除了幾個參數(shù)外基本上都

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論