• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            羅朝輝(飄飄白云)

            關(guān)注嵌入式操作系統(tǒng),移動(dòng)平臺(tái),圖形開發(fā)。-->加微博 ^_^

              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              85 隨筆 :: 0 文章 :: 169 評論 :: 0 Trackbacks

            終于啃完了《Head First design patterns》,順便把用Google筆記本所做的筆記貼出來記錄下~~

             
            OO基礎(chǔ) 
             
            抽象, 封裝,多型,繼承
             
            OO原則
             
            1,封裝變化
            2,多用組合,少用繼承
            3,針對接口編程,不針對實(shí)現(xiàn)編程
            4,為交互對象之間的松耦合設(shè)計(jì)而努力
            5,為擴(kuò)展開放,對修改關(guān)閉
            6,依賴倒置原則(Dependency Inversion Principle)
            7,最少知識(shí)原則(Least Knowledge),只和你的密友談話。
            8,好萊塢原則:別調(diào)用我們,我們會(huì)調(diào)用你。
            9,單一責(zé)任原則:一個(gè)類應(yīng)該只有以一個(gè)引起變化的原因。
             
            1,封裝變化
             --策略模式(封裝不同的算法--鴨子示例)
             
            2,多用組合,少用繼承
             --策略模式(組合算法--鴨子示例)
             
            3,針對接口編程,不針對實(shí)現(xiàn)編程
             
             
            4,為交互對象之間的松耦合設(shè)計(jì)而努力
             --觀察者模式(出版者/訂閱者--天氣預(yù)報(bào)與布告板示例)
             
            5,對擴(kuò)展開放,對修改關(guān)閉
             --裝飾者模式(咖啡與調(diào)料示例,java的IO庫示例)
             
            6,要依賴抽象,不要依賴具體類。
             --工廠方法模式(pizza店與pizza示例)
             --抽象工廠模式(pizza與原料示例)
             
             7,最少知識(shí)原則
             --外觀模式(家庭影院示例)
             
             8,好萊塢原則:別調(diào)用我們,我們會(huì)調(diào)用你
             在好萊塢原則下,我們允許底層組件將自己掛鉤到系統(tǒng)上,但是高層組件會(huì)決定什么時(shí)候和怎樣使用這些低層組件。換句話說,高層組件對待低層組件的方式是“別調(diào)用我們,我們會(huì)調(diào)用你”
             --模板方法模式(泡咖啡和泡茶示例)
             
            9,單一責(zé)任原則
            -迭代器模式(不同的菜單實(shí)現(xiàn)與女招待:ArrayList與數(shù)組)
            設(shè)計(jì)模式


            第一章  Strategy-策略模式
             
            策略模式:定義算法族,分別封裝起來,讓他們之間可以互相替換,此模式讓算法的變化獨(dú)立于使用算法的客戶。
            第二章 Observer-觀察者模式
             
            觀察者模式:定義了對象之間的一對多依賴,這樣一來,當(dāng)一個(gè)對象改變狀態(tài)時(shí),它的所有依賴者都會(huì)受到通知并自動(dòng)更新。 
            第三章 裝飾者模式
             
            裝飾者模式定義:動(dòng)態(tài)地將責(zé)任附加到對象上,若要擴(kuò)展功能,裝飾者提供了比繼承更有彈性的替代方案。
             
            示例:starbuzz 星巴克咖啡調(diào)料價(jià)格
             
            設(shè)計(jì)原則:類應(yīng)該對擴(kuò)展開放,對修改關(guān)閉。 
             
            解釋:
            1,裝飾者和被裝飾者對象有相同的超類型;
            2,既然裝飾者和被裝飾者對象有相同的超類型,所以在任何需要原始對象(被包裝的)的場合,可以用裝飾過的對象替代它。
            3,裝飾者可以在所委托被裝飾者的行為之前與/或之后,加上自己的行為,已達(dá)到特定的目的。
            4,對象可以在任何時(shí)候被裝飾,所以可以在運(yùn)行時(shí)動(dòng)態(tài)地,不限量地用你喜歡的裝飾者來裝飾對象。
             
            要點(diǎn):
            --組合和委托可用于在運(yùn)動(dòng)時(shí)動(dòng)態(tài)地加上新的行為;
            --除了繼承,裝飾者模式也可以讓我們擴(kuò)展行為;
            --裝飾者模式意味著一群裝飾者類,這些類用來包裝具體組件;
            --裝飾者類反映出被裝飾的組件類型(事實(shí)上,他們具有相同的類型,都經(jīng)過接口或繼承實(shí)現(xiàn))
            --你可以用無數(shù)個(gè)裝飾者包裝一個(gè)組件
            --裝飾者一般對組件的客戶是透明的,除非客戶程序依賴于組件的具體類型;
            --裝飾者會(huì)導(dǎo)致設(shè)計(jì)中出現(xiàn)許多小對象,如果過度使用,會(huì)讓程序變得很復(fù)雜。
             
            第四章 Factory Method-工廠方法模式 與Abstact Factory Method -抽象工廠模式
             
            工廠方法模式定義了一個(gè)創(chuàng)建對象的接口,但有子類決定要實(shí)例化的類似哪一個(gè)。工廠方法讓類把實(shí)例化推遲到子類。 
             
            抽象工廠模式提供一個(gè)接口,用于創(chuàng)建相關(guān)或依賴對象的家族,而不需要明確指定具體類。
             
            要點(diǎn):
            -所有的工廠都是用來封裝對象的創(chuàng)建。
            -簡單工廠,雖然不是真正的設(shè)計(jì)模式,但仍不失為一個(gè)簡單的方法,可以將客戶程序從具體類解耦。
            -工廠方法使用繼承:把對象的創(chuàng)建委托給子類,子類實(shí)現(xiàn)工廠方法來創(chuàng)建對象。
            -抽象工廠使用對象組合:對象的創(chuàng)建被實(shí)現(xiàn)在工廠接口所暴露出來的方法中。
            -所有工廠模式都通過減少應(yīng)用程序與具體類之間的依賴性促進(jìn)松耦合。
            -工廠方法允許類將實(shí)例化延遲到子類進(jìn)行。
            抽象工廠創(chuàng)建相關(guān)的對象家族,而不需要依賴他們的具體類。
            -依賴倒置原則,指導(dǎo)我們避免依賴具體類型,而要 盡量依賴抽象。
            -工廠是很有威力的技巧,幫助我們針對抽象編程,而不要針對具體類編程。
             
            第五章 Singleton- 單件模式
             
            單件模式-確保一個(gè)類只有一個(gè)實(shí)例,并提供一個(gè)全局訪問點(diǎn)。
             
             
            第六章 命令模式 
             
            命令模式將請求封裝成對象,這可以讓你使用不同的請求,隊(duì)列,或者日志請求來參數(shù)化其他對象。命令模式也可以支持撤銷操作。
             
             示例:遙控器
             
             第七章 Adapter-適配器模式和Facade-外觀模式
             
            適配器模式將一個(gè)類的接口,轉(zhuǎn)換成客戶期望的另一個(gè)接口。適配器讓原本接口不兼容的類可以合作無間。
             
            有兩種分類:類適配器和對象適配器。
             
            適配器模式示例:火雞變鴨子,JDK的迭代器
            外觀模式示例:家庭影院
            第八章 模板方法模式
             
            模板方法模式在一個(gè)方法(稱為模板方法)中定義了一個(gè)算法的骨架,而將一些步驟延遲到子類中。模板方法使得子類可以在不改變算法結(jié)構(gòu)的情況下,重新定義算法中的某些步驟。
             
            鉤子(hook)是一種被聲明在抽象類中的方法,但只有空的或者默認(rèn)的實(shí)現(xiàn)。鉤子的存在可以讓子類有能力對算法的不同點(diǎn)進(jìn)行掛鉤,要不要掛鉤,由子類自行決定。
             
            示例:泡咖啡和泡茶
             
            要點(diǎn):
            -模板方法定義了算法的步驟,把這些步驟的實(shí)現(xiàn)延遲到子類。
            -模板方法模式為我們提供了一種代碼復(fù)用的重要技巧。
            -模板方法的抽象類可以定義具體方法,抽象方法和鉤子。
            -抽象方法由子類實(shí)現(xiàn)。
            -鉤子是一種方法,它在抽象類中不做事,或者只做默認(rèn)的事情,子類可以選擇要不要去覆蓋它。
            -好萊塢原則告訴我們,將決策權(quán)放在高層模塊中, 以便決定如何以及何時(shí)調(diào)用低層模塊。
            -策略模式和模板方法模式都封裝算法,一個(gè)用組合,另一個(gè)用繼承。
            -工廠方法是模板方法的一個(gè)特殊版本。
              
            第九章 迭代器(Iterator)與組合模式(Composite)--管理良好的集合
             
            迭代器模式提供一個(gè)方法順序訪問一個(gè)聚合對象中的各個(gè)元素,而又不暴露其內(nèi)部的表示。
             
            組合模式允許你將對象組合成樹形結(jié)構(gòu)來表現(xiàn)“整體/部分”層次結(jié)構(gòu)。組合能讓客戶以一致的方式處理個(gè)別對象以及對象組合。
             
            示例:菜單及其子菜單(樹形結(jié)構(gòu))
             
             組合模式讓我們能用樹形方式創(chuàng)建對象的結(jié)構(gòu),樹里面包含了組合以及個(gè)別的對象。使用組合結(jié)構(gòu),我們能把相同的操作應(yīng)用在組合和個(gè)別對象上。換句話說,在大多數(shù)情況下,我們可以忽略對象組合和個(gè)別對象之間的差別。
             
            何時(shí)使用組合模式:當(dāng)你有數(shù)個(gè)對象的集合,它們之間有“整體/部分”的關(guān)系,并且你想用一致方式對待這些對象時(shí),就可以使用組合模式。
            第十章 狀態(tài)模式
             
            狀態(tài)模式允許對象在內(nèi)部狀態(tài)改變時(shí)改變它的行為,對象看起來好像修改了它的類。
             
            狀態(tài)模式將狀態(tài)封裝成為獨(dú)立的類,并將動(dòng)作委托到代表當(dāng)前狀態(tài)的對象。從客戶的視角來看:如果說你使用的對象能夠完全改變它的行為,那么你會(huì)覺得,這個(gè)對象實(shí)際上是別的類實(shí)例化而來的,然而,實(shí)際上,你知道我們是使用組合通過簡單引用不同的狀態(tài)對象來造成類改變的假象。
             
             策略模式和狀態(tài)模式是雙胞胎,他們的類圖完全相同,只是各自的意圖不同。策略模式是圍繞可以互換的算法來創(chuàng)建成功業(yè)務(wù)的,而狀態(tài)模式是通過改變對象內(nèi)部的狀態(tài)來幫助對象控制自己的行為。
             
            以狀態(tài)模式而言,我們將一群行為封裝在狀態(tài)對象中,context的行為隨時(shí)可以委托到那些狀態(tài)對象中的一個(gè)。隨著時(shí)間的流逝,當(dāng)前狀態(tài)在狀態(tài)對象集合中游走改變,以反映出context內(nèi)部的狀態(tài),因此,context的行為也會(huì)跟著改變。但是context的客戶對于狀態(tài)對象了解不多,甚至根本是渾然不覺。
             
            狀態(tài)類會(huì)使設(shè)計(jì)中類的數(shù)目大量增加。
            第十一章 代理模式(proxy)
             
             代理模式為另一個(gè)對象提供一個(gè)替身或占位符以控制對這個(gè)對象的訪問。
             
            使用代理模式創(chuàng)建代表(Representative)對象,讓代表對象控制某對象的訪問,被代理的對象可以是遠(yuǎn)程的對象,創(chuàng)建開銷大的對象或需要安全控制的對象。
             
            -遠(yuǎn)程代理控制訪問遠(yuǎn)程對象(java中的RMI)
            -虛擬代理控制訪問創(chuàng)建開銷大的資源(遠(yuǎn)程圖片顯示)
            -保護(hù)代理基于權(quán)限控制對資源的訪問
             
            第十二章 復(fù)合模式(Compound)
             
            -模式通常被一起使用,并被組合在同一個(gè)設(shè)計(jì)解決方案中。
            -復(fù)合模式在一個(gè)解決方案中結(jié)合兩個(gè)或多個(gè)模式,以解決一般或重復(fù)發(fā)生的問題。
             
            示例:鴨子與鵝(適配器,迭代模式,觀察者,抽象工廠,策略模式)
             
            MVC:模型視圖控制器(策略,觀察者,組合模式)
             
            第十三章 真實(shí)生活中的模式 
             
            -讓設(shè)計(jì)模式自然而然地出現(xiàn)在你的設(shè)計(jì)中,而不是為了使用而使用。
            -設(shè)計(jì)模式并非僵化的教條,你可以依據(jù)自己的需要采用或調(diào)整。
            -總是使用滿足需要的最簡單解決方案,不管它用不用模式。
            -學(xué)習(xí)設(shè)計(jì)模式的類目,可以幫你自己熟悉這些模式以及它們之間的關(guān)系。
             
            模式的分類:
             
            創(chuàng)建型,結(jié)構(gòu)型與行為模式
             
            創(chuàng)建型模式:抽象工廠模式,生成器模式,工廠方法模式,原型模式,單件模式
             
            結(jié)構(gòu)型模式: 適配器模式,橋接模式,組合模式,裝飾者模式,外觀模式,享元模式,代理模式
             
            行為模式:職責(zé)鏈模式,命令模式,解釋器模式,迭代器模式,中介者模式,備忘錄模式,觀察者模式,狀態(tài)模式,策略模式,模板方法模式,訪問者模式
             
            類模式和對象模式
             
            類模式:模板方法模式(Template method),工廠方法模式(Factory method),適配器模式(Adapter),解釋器模式(Interpreter)
             
            對象模式:組合模式(),訪問者模式,外觀模式,代理模式,策略模式,橋接模式,享元模式,抽象工廠模式,單件模式,迭代器模式,命令模式,備忘錄模式,觀察者模式,職責(zé)鏈模式,中介者模式,原型模式,生成器模式
             
            總結(jié):
            裝飾者模式:包裝一個(gè)對象,以提供新的行為。
            適配器模式:封裝對象,并提供不同的接口。
            模板方法模式:由子類決定如何實(shí)現(xiàn)一個(gè)算法中的步驟。
            工廠方法模式:由子類決定要?jiǎng)?chuàng)建的具體類似哪一個(gè)。
            單件模式:確保有且只有一個(gè)對象被創(chuàng)建。
            策略模式:封裝可以互換的行為,并使用委托來決定要使用哪一個(gè)。
            組合模式:客戶用一致的方式處理對象集合和單個(gè)對象。
            狀態(tài)模式:封裝了基于狀態(tài)的行為,并使用委托在行為之間切換。
            迭代器模式:在對象的集合之中游走,而不是暴露集合的實(shí)現(xiàn)。
            外觀模式:簡化一群類的接口。
            裝飾者模式:包裝一個(gè)對象,以提供新的行為。
            抽象工廠方法:允許客戶創(chuàng)建對象的家族,而無需指定他們的具體類。
            觀察者模式:讓對象能夠在狀態(tài)改變時(shí)被通知。
            代理模式:包裝對象,以控制對此對象的訪問。
            命令模式:封裝請求成為對象。
             
             
            附錄A 剩余的模式


            橋接模式(Bridge)
            使用橋接模式不只改變你的實(shí)現(xiàn),也改變你的抽象。橋接模式通過將實(shí)現(xiàn)和抽象放在兩個(gè)不同的類層次中而使它們可以獨(dú)立改變。
             
            橋接的優(yōu)點(diǎn):
            -將實(shí)現(xiàn)予以解耦,讓它和界面之間不再永久綁定。
            -抽象和實(shí)現(xiàn)可以獨(dú)立擴(kuò)展,不會(huì)影響到對方。
            -對于“具體的抽象類”所做的改變,不會(huì)影響到客戶。
             
            橋接的用途和缺點(diǎn):
            -適合使用在需要跨越多個(gè)平臺(tái)的圖形和窗口系統(tǒng)上。
            -當(dāng)需要用不同的方法改變接口和實(shí)現(xiàn)時(shí),你會(huì)發(fā)現(xiàn)橋接模式很好用。
            -橋接模式的缺點(diǎn)是增加了復(fù)雜度。
             
             示例:控制器與界面各自的抽象
             
            生成器模式(Builder)
            -使用生成器模式封裝一個(gè)產(chǎn)品的構(gòu)造過程,并允許按步驟構(gòu)造。
             
            生成器的優(yōu)點(diǎn):
            -將一個(gè)復(fù)雜對象的創(chuàng)建過程封裝起來。
            -允許對象通過多個(gè)步驟來創(chuàng)建,并且可以改變過程(這和只有一個(gè)步驟的工程模式不同)。
            -向客戶隱藏產(chǎn)品內(nèi)部的實(shí)現(xiàn)。
            -產(chǎn)品的實(shí)現(xiàn)可以被替換,因?yàn)榭蛻糁豢吹揭粋€(gè)抽象的接口。
             
            生成器的用途和缺點(diǎn):
            -經(jīng)常被用來創(chuàng)建組合結(jié)構(gòu)
            -與工廠模式相比,采用生成器模式創(chuàng)建對象的客戶,需要具備更多的領(lǐng)域知識(shí)。
             
            示例:度假計(jì)劃
             
             責(zé)任鏈模式(Chain of responsibility)
            當(dāng)你想要讓一個(gè)以上的對象有機(jī)會(huì)能夠處理某個(gè)請求的時(shí)候,就使用責(zé)任鏈模式。
             
             責(zé)任鏈模式的優(yōu)點(diǎn):
            -將請求的發(fā)送者和接受者解耦
            -可以簡化你的對象,因?yàn)樗恍枰梨湹慕Y(jié)構(gòu)
            -通過改變鏈內(nèi)的成員或調(diào)動(dòng)它們的次序,允許你動(dòng)態(tài)地新增或者刪除責(zé)任
             
             責(zé)任鏈的用途與缺點(diǎn):
            -經(jīng)常被使用在窗口系統(tǒng)中,處理鼠標(biāo)和鍵盤之類的事件
            -并不保證請求一定會(huì)被執(zhí)行;如果沒有任何對象處理它的話,它可能會(huì)落到鏈尾之外(這可以是優(yōu)點(diǎn)也可以是缺點(diǎn))
            -可能不容易觀察運(yùn)行時(shí)的特征,有礙于除錯(cuò)
             
            示例:不同郵件(垃圾郵件,F(xiàn)ans郵件,客服郵件,業(yè)務(wù)郵件等)的處理
             
            享元模式(Flyweight)
            如想讓某個(gè)類的一個(gè)實(shí)例能用來提供許多“虛擬實(shí)例”,就是用享元模式
             
            享元模式的優(yōu)點(diǎn):
            -減少運(yùn)行時(shí)對象實(shí)例的個(gè)數(shù),節(jié)省內(nèi)存
            -將許多“虛擬對象”的狀態(tài)集中管理
             
            享元模式的用途與缺點(diǎn):
            -當(dāng)一個(gè)類有許多的實(shí)例,而這些實(shí)例能被同一方法控制的時(shí)候,我們就可以使用享元模式
            -缺點(diǎn):一旦你實(shí)現(xiàn)了它,那么單個(gè)的邏輯實(shí)例將無法擁有獨(dú)立而不同的處理
             
            享元模式
            示例:景觀設(shè)計(jì)中的點(diǎn)綴樹的顯示(只一個(gè)樹實(shí)例,共享位置年輪信息)
             
            解釋器模式(Intepreter)
            使用解釋器模式為語言創(chuàng)建解釋器
             
            解釋器的優(yōu)點(diǎn):
            -將每一個(gè)語法規(guī)則表示成一個(gè)類,方便于實(shí)現(xiàn)語言
            -因?yàn)檎Z法由許多類表示,所以你可以輕易地改變或擴(kuò)展此語言
            -通過在類結(jié)構(gòu)中加入新的方法,可以在解釋的同時(shí)增加新的行為,例如打印格式的美化或者進(jìn)行復(fù)雜的程序驗(yàn)證
             
            解釋器的用途與缺點(diǎn):
            -當(dāng)你需要實(shí)現(xiàn)一個(gè)簡單的語言時(shí),使用解釋器
            -當(dāng)你有一個(gè)簡單的語法,而且簡單比效率更重要時(shí),使用解釋器
            -可以處理腳本語言和編程語言
            -當(dāng)語言規(guī)則的數(shù)碼太大時(shí),這個(gè)模式可能會(huì)變得相當(dāng)繁雜,在這種情況下,使用解釋器/編譯器的產(chǎn)生器可能更合適
             
            示例:Duck pond控制鴨子的語言解釋器
            中介者模式(Mediator)
            使用中介者模式來集中相關(guān)對象之間復(fù)雜的溝通和控制方式。每個(gè)對象都會(huì)在自己的狀態(tài)改變時(shí),告訴中介者,每個(gè)對象都會(huì)對中介者所發(fā)出的請求作出反應(yīng)。中介者內(nèi)包含了整個(gè)系統(tǒng)的控制邏輯。當(dāng)某個(gè)對象需要一個(gè)新的規(guī)則時(shí),或者是一個(gè)新的對象被加入系統(tǒng)內(nèi),其所有需要用到的邏輯也都被加入中介者內(nèi)。
             
            中介者模式的優(yōu)點(diǎn):
            -通過將對象彼此解耦,可以增加對象的復(fù)用性
            -通過將控制邏輯集中,可以簡化系統(tǒng)維護(hù)
            -可以讓對象之間所傳遞的消息變得簡單而且大幅減少
             
            中介者模式的用途和缺點(diǎn):
            -中介者模式常常被用來協(xié)調(diào)相關(guān)的GUI組件
            -中介者模式的缺點(diǎn)是:如果設(shè)計(jì)不當(dāng),中介者對象本身會(huì)變得過于復(fù)雜
             
            示例:生活自動(dòng)機(jī)(鬧鈴,煮咖啡,日歷,噴頭)
             
            備忘錄模式(Memento)
            當(dāng)你需要讓對象返回之前的狀態(tài)時(shí)(例如:undo),就使用備忘錄模式。備忘錄模式有兩個(gè)目標(biāo):儲(chǔ)存系統(tǒng)關(guān)鍵對象的重要狀態(tài);維護(hù)關(guān)鍵對象的封裝。請不要忘記單一責(zé)任原則,不要把保持狀態(tài)的工作和關(guān)鍵對象混在一起,這樣比較好。這個(gè)專門掌握狀態(tài)的對象就稱為備忘錄。
             
            備忘錄模式的優(yōu)點(diǎn):
            -被儲(chǔ)存的狀態(tài)放在外面,不要和關(guān)鍵對象混在一起,這可以幫助維護(hù)內(nèi)聚
            -保持關(guān)節(jié)對象的數(shù)據(jù)封裝
            -提供了容易實(shí)現(xiàn)的恢復(fù)能力
             
            備忘錄模式的用途和缺點(diǎn):
            -備忘錄用于儲(chǔ)存狀態(tài)
            -使用備忘錄的缺點(diǎn):儲(chǔ)存和恢復(fù)狀態(tài)的過程可能相當(dāng)耗時(shí)
            -在Java系統(tǒng)中,其實(shí)可以考慮使用序列化(Serialization)機(jī)制儲(chǔ)存系統(tǒng)的狀態(tài)
             
            示例:游戲中的存儲(chǔ)進(jìn)度功能
             
             原型模式(Prototype)
            當(dāng)創(chuàng)建給定類的實(shí)例的過程很昂貴或很復(fù)雜時(shí),就使用原型模式。原型模式允許你通過使用復(fù)制現(xiàn)有的實(shí)例來創(chuàng)建新的實(shí)例(在Java中,這通常意味著使用clone()方法或者反序列化)。這個(gè)模式的重點(diǎn)在于,客戶的代碼在不知道要實(shí)例化何種特定類的情況下,可以制造出新的實(shí)例。
             
            原型模式的優(yōu)點(diǎn):
            -向客戶隱藏制造新實(shí)例的復(fù)雜性
            -提供客戶能夠產(chǎn)生未知類型對象的選項(xiàng)
            -在某些環(huán)境下,復(fù)制對象比創(chuàng)建新對象更有效
             
            原型模式的用途和缺點(diǎn):
            -在一個(gè)復(fù)雜的類層次中,當(dāng)系統(tǒng)必須從其中的許多類型創(chuàng)建新對象時(shí),可以考慮原型
            -缺點(diǎn):對象的復(fù)制有時(shí)相當(dāng)復(fù)雜
             
            示例:在游戲中創(chuàng)建各式各樣的怪獸
             
            訪問者模式(Visitor)
            當(dāng)你想要為一個(gè)對象的組合增加新的能力,且封裝并不重要時(shí),就使用訪問者模式。
             
            客戶要求訪問者從組合結(jié)構(gòu)中取得信息,新方法可以被加入到訪問者中,而不會(huì)影響組合;訪問者需要能夠調(diào)用組合類的getState(),而這也正是你能夠加入新方法以讓客戶使用的地方;所有的這些組合類必須做的事情就是加入一個(gè)getState()方法,而不必?fù)?dān)心暴露他們自己。
             
            訪問者模式的優(yōu)點(diǎn):
            -允許你對組合結(jié)構(gòu)加入新的操作,而不需改變結(jié)構(gòu)本身
            -想要加入新的操作,相對容易
            -訪問者所進(jìn)行的操作,其代碼是集中在一起的
             
            訪問者模式的用途和缺點(diǎn):
            -當(dāng)采用訪問者模式的時(shí)候,就會(huì)打破組合類的封裝
            -因?yàn)橛巫叩墓δ軤可嫫渲校詫M合結(jié)構(gòu)的改變就更加困難
             
            示例:對鄉(xiāng)村餐廳的菜單添加營養(yǎng)成分,能量顯示
            posted on 2008-07-20 23:31 羅朝輝 閱讀(979) 評論(0)  編輯 收藏 引用 所屬分類: C/C++
            久久综合久久综合亚洲| 久久无码AV中文出轨人妻 | 精品国产福利久久久| 久久亚洲中文字幕精品有坂深雪 | 一本大道久久a久久精品综合| 亚洲成人精品久久| 精品久久综合1区2区3区激情| 亚洲精品tv久久久久久久久久| 欧美久久久久久| 91久久福利国产成人精品| 伊人久久精品影院| 国产综合精品久久亚洲| 国产偷久久久精品专区| 久久99精品久久久久久野外| 久久婷婷激情综合色综合俺也去 | 亚洲AV无码久久精品成人| 欧美精品福利视频一区二区三区久久久精品 | 久久亚洲精品中文字幕三区| 99精品国产99久久久久久97| 亚洲国产天堂久久综合| 伊人久久大香线蕉AV一区二区| 国产精品九九九久久九九| 情人伊人久久综合亚洲| 久久青青草原综合伊人| 国产成人精品综合久久久| 久久国产精品99久久久久久老狼 | 国产99久久精品一区二区| 久久精品国产亚洲AV嫖农村妇女 | 精品久久久久久中文字幕人妻最新| 四虎影视久久久免费观看| 久久国产精品免费一区二区三区 | 亚洲国产成人精品女人久久久| 成人午夜精品久久久久久久小说| 久久影视综合亚洲| 国产美女亚洲精品久久久综合| 久久久噜噜噜久久熟女AA片| 99久久免费国产特黄| 久久亚洲国产成人影院| 精品综合久久久久久888蜜芽| 久久男人AV资源网站| 久久狠狠高潮亚洲精品|