1.抽象工廠: Factory
提供一個創(chuàng)建一系列或相關(guān)依賴對象的接口譬涡，而無需指定他們具體的類八匠。針對多級結(jié)構(gòu).
抽象工廠模式除了具有工廠方法模式的優(yōu)點(diǎn)外崎淳，最主要的優(yōu)點(diǎn)就是可以在類的內(nèi)部對產(chǎn)品族進(jìn)行約束蝇裤。
產(chǎn)品族的擴(kuò)展將是一件十分費(fèi)力的事情掷漱，假如產(chǎn)品族中需要增加一個新的產(chǎn)品全封，
則幾乎所有的工廠類都需要進(jìn)行修改马昙。
適用場景
當(dāng)需要創(chuàng)建的對象是一系列相互關(guān)聯(lián)或相互依賴的產(chǎn)品族時桃犬，便可以使用抽象工廠模式。
2.建造者: Builder
將一個復(fù)雜對象的構(gòu)建與它的表示分離行楞，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示攒暇。
使用建造者模式的好處
1.使用建造者模式可以使客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)。
2.具體的建造者類之間是相互獨(dú)立的子房，對系統(tǒng)的擴(kuò)展非常有利形用。
3.由于具體的建造者是獨(dú)立的，因此可以對建造過程逐步細(xì)化证杭，而不對其他的模塊產(chǎn)生任何影響尾序。
使用建造者模式的場合:
1.創(chuàng)建一些復(fù)雜的對象時，這些對象的內(nèi)部組成構(gòu)件間的建造順序是穩(wěn)定的躯砰，但是
對象的內(nèi)部組成構(gòu)件面臨著復(fù)雜的變化每币。
2.要創(chuàng)建的復(fù)雜對象的算法，獨(dú)立于該對象的組成部分琢歇，也獨(dú)立于組成部分的裝配方法時兰怠。
3.工廠方法:Factory Method
定義一個用于創(chuàng)建對象的接口，讓子類決定實(shí)例化哪一個類李茫，工廠模式使一個類的
實(shí)例化延遲到其子類揭保。針對單一結(jié)構(gòu)系統(tǒng).
適用場景：
作為一種創(chuàng)建類模式，在任何需要生成復(fù)雜對象的地方魄宏，都可以使用工廠方法模式
假如調(diào)用者自己組裝產(chǎn)品需要增加依賴關(guān)系時秸侣，可以考慮使用工廠模式。
當(dāng)需要系統(tǒng)有比較好的擴(kuò)展性時宠互，可以考慮工廠模式
4.原型:Prototype
用原型實(shí)例指定創(chuàng)建對象的種類味榛，并且通過拷貝這些原型創(chuàng)建新的對象。
使用原型模式創(chuàng)建對象比直接new一個對象在性能上要好的多予跌，因?yàn)镺bject類的clone方法是一個本地方法搏色，
它直接操作內(nèi)存中的二進(jìn)制流，特別是復(fù)制大對象時券册，性能的差別非常明顯频轿。
使用原型模式的另一個好處是簡化對象的創(chuàng)建，使得創(chuàng)建對象就像我們在編輯文檔時的復(fù)制粘貼一樣簡單烁焙。
因?yàn)橐陨蟽?yōu)點(diǎn)航邢，所以在需要重復(fù)地創(chuàng)建相似對象時可以考慮使用原型模式。比如需要在一個
循環(huán)體內(nèi)創(chuàng)建對象骄蝇，假如對象創(chuàng)建過程比較復(fù)雜或者循環(huán)次數(shù)很多的話膳殷，使用原型模式不但可以簡化創(chuàng)建過程，
而且可以使系統(tǒng)的整體性能提高很多乞榨。
5.單例:Singleton
保證一個類僅有一個實(shí)例秽之，并提供一個訪問它的全局訪問點(diǎn).
讓類自身負(fù)責(zé)保存它的唯一實(shí)例当娱，這個類可以保證沒有其他實(shí)例可以被創(chuàng)建，
并且我還提供了一個訪問該實(shí)例的方法考榨。這樣就使得對唯一的實(shí)例可以嚴(yán)格
地控制客戶怎樣以及何時訪問它跨细。
6.適配器:Adapter
將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。適配器模式使得原本由于
接口不兼容而不能一起工作的那些類可以一起工作河质。
優(yōu)點(diǎn):
通過適配器冀惭，客戶端可以調(diào)用同一接口，因而對客戶端來說是透明的掀鹅。這樣做更簡單散休、更直接、更緊湊乐尊。
復(fù)用了現(xiàn)存的類戚丸，解決了現(xiàn)存類和復(fù)用環(huán)境要求不一致的問題。
將目標(biāo)類和適配者類解耦扔嵌，通過引入一個適配器類重用現(xiàn)有的適配者類限府，而無需修改原有代碼。
一個對象適配器可以把多個不同的適配者類適配到同一個目標(biāo)痢缎，也就是說胁勺，
同一個適配器可以把適配者類和它的子類都適配到目標(biāo)接口。
缺點(diǎn):
對于對象適配器來說独旷，更換適配器的實(shí)現(xiàn)過程比較復(fù)雜署穗。
適用場景:
系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的接口嵌洼。
想要建立一個可以重用的類案疲，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進(jìn)的類一起工作咱台。
兩個類所做的事情相同或相似络拌，但是具有不同接口的時候。
舊的系統(tǒng)開發(fā)的類已經(jīng)實(shí)現(xiàn)了一些功能回溺，但是客戶端卻只能以另外接口的形式訪問，
但我們不希望手動更改原有類的時候混萝。
使用第三方組件遗遵，組件接口定義和自己定義的不同，不希望修改自己的接口逸嘀，但是要使用第三方組件接口的功能车要。
7.橋接:Bridge
將抽象不笨與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化.
橋接模式的使用場景:
1崭倘、當(dāng)一個對象有多個變化因素的時候翼岁，通過抽象這些變化因素类垫，將依賴具體實(shí)現(xiàn)，修改為依賴抽象琅坡。
2悉患、當(dāng)某個變化因素在多個對象中共享時。我們可以抽象出這個變化因素榆俺，然后實(shí)現(xiàn)這些不同的變化因素售躁。
3、當(dāng)我們期望一個對象的多個變化因素可以動態(tài)的變化茴晋，而且不影響客戶的程序的使用時陪捷。
8.組合(合成):
將對象組合成樹形結(jié)構(gòu)以表示‘部分-整體’的層次結(jié)構(gòu)，組合模式使得用戶
對單個對象和組合對象的使用具有一致性诺擅。
使用場景:
當(dāng)發(fā)現(xiàn)需求中是體現(xiàn)部分與整體層次結(jié)構(gòu)時市袖，以及你希望用戶可以忽略組合對象與單個對象的不同，
統(tǒng)一地使用組合結(jié)構(gòu)中的所有對象時烁涌，就應(yīng)該考慮組合模式了苍碟。
9.裝飾:Decorator
動態(tài)地給一個對象添加一些額外的職責(zé)。就增加功能來說烹玉，裝飾模式相比生成子類更加靈活驰怎。
1.在不影響其他對象的情況下，以動態(tài)二打、透明的方式給單個對象添加職責(zé)县忌。
2 處理那些可以撤消的職責(zé)。
3.當(dāng)不能采用生成子類的方法進(jìn)行擴(kuò)充時继效。一種情況是症杏，可能有大量獨(dú)立的擴(kuò)展，
為支持每一種組合將產(chǎn)生大量的子類瑞信，使得子類數(shù)目呈爆炸性增長厉颤。
另一種情況可能是因?yàn)轭惗x被隱藏，或類定義不能用于生成子類凡简。
10.外觀:Facade
為子系統(tǒng)中的一組接口提供一個一致的界面逼友，外觀模式定義了一個高層接口，
這個接口使得這一子系統(tǒng)更加容易使用秤涩。
適用環(huán)境:
在開發(fā)階段帜乞，子系統(tǒng)往往因?yàn)椴粩嗟闹貥?gòu)演化而變得越來越復(fù)雜，
增加外觀Facade可以提供一個簡單的接口筐眷，減少它們之間的依賴.
在維護(hù)一個遺留的大型系統(tǒng)時黎烈，可能這個系統(tǒng)已經(jīng)非常難以維護(hù)和擴(kuò)展了，可以為
新系統(tǒng)開發(fā)一個外觀Facade類，來提供設(shè)計粗糙或高度復(fù)雜的遺留代碼的比較清晰
簡單的接口照棋，讓新系統(tǒng)與Facade對象交互资溃，F(xiàn)acade與遺留代碼交互所有復(fù)雜的工作。
優(yōu)點(diǎn):
實(shí)現(xiàn)了子系統(tǒng)與客戶端之間的松耦合關(guān)系烈炭。
客戶端屏蔽了子系統(tǒng)組件溶锭，減少了客戶端所需處理的對象數(shù)目，并使得子系統(tǒng)使用起來更加容易梳庆。
11.享元:Flyweight
為運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對象暖途。
優(yōu)點(diǎn):
1、享元模式的優(yōu)點(diǎn)在于它能夠極大的減少系統(tǒng)中對象的個數(shù)。
2、享元模式由于使用了外部狀態(tài)矢空，外部狀態(tài)相對獨(dú)立，不會影響到內(nèi)部狀態(tài)欺栗，
所以享元模式使得享元對象能夠在不同的環(huán)境被共享。
缺點(diǎn)
1征峦、由于享元模式需要區(qū)分外部狀態(tài)和內(nèi)部狀態(tài)迟几，使得應(yīng)用程序在某種程度上來說更加復(fù)雜化了。
2栏笆、為了使對象可以共享类腮，享元模式需要將享元對象的狀態(tài)外部化，而讀取外部狀態(tài)使得運(yùn)行時間變長蛉加。
模式適用場景
1蚜枢、如果一個系統(tǒng)中存在大量的相同或者相似的對象，由于這類對象的大量使用针饥，會造成系統(tǒng)內(nèi)存的耗費(fèi)厂抽，
可以使用享元模式來減少系統(tǒng)中對象的數(shù)量。
2丁眼、對象的大部分狀態(tài)都可以外部化筷凤，可以將這些外部狀態(tài)傳入對象中。
12.代理:Proxy
為其他對象提供一種代理以控制對這個對象的訪問苞七。在某些情況下藐守，一個對象不適合或者不能直接引用
另一個對象，而代理對象可以在客戶端和目標(biāo)對象之間起到中介的作用蹂风。
代理模式常被分為遠(yuǎn)程代理吗伤、虛擬代理、保護(hù)代理等等硫眨。
優(yōu)點(diǎn)：
1）代理模式能將代理對象與真正被調(diào)用的對象分離，在一定程度上降低了系統(tǒng)的耦合度。
2）代理模式在客戶端和目標(biāo)對象之間起到一個中介作用礁阁，這樣可以起到保護(hù)目標(biāo)對象的作用巧号。
代理對象也可以對目標(biāo)對象調(diào)用之前進(jìn)行其他操作。
缺點(diǎn)：
1）在客戶端和目標(biāo)對象增加一個代理對象姥闭，會造成請求處理速度變慢丹鸿。
2）增加了系統(tǒng)的復(fù)雜度。
使用場景：
1）遠(yuǎn)程代理棚品，也就是為一個對象在不同的地址空間提供局部代表靠欢。這樣可以隱藏一個對象存在于
不同地址空間的事實(shí)。
2）虛擬代理铜跑，根據(jù)需要創(chuàng)建開銷很大的對象门怪。通過它來存放實(shí)例化需要很長時間的對象。
3）安全代理锅纺，用來控制真實(shí)對象訪問時的權(quán)限掷空。
4）智能指引，當(dāng)調(diào)用目標(biāo)對象時囤锉，代理可以處理其他的一些操作坦弟。
13.觀察者:Observer
定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時官地，所有
依賴與它的對象都得到通知并被自動更新.
優(yōu)點(diǎn):
觀察者模式解除了主題和具體觀察者的耦合酿傍，讓耦合的雙方都依賴于抽象，而不是依賴具體驱入。
從而使得各自的變化都不會影響另一邊的變化赤炒。
缺點(diǎn):
依賴關(guān)系并未完全解除，抽象通知者依舊依賴抽象的觀察者沧侥。
適用場景:
當(dāng)一個對象的改變需要給變其它對象時可霎，而且它不知道具體有多少個對象有待改變時。
一個抽象某型有兩個方面宴杀，當(dāng)其中一個方面依賴于另一個方面癣朗，這時用觀察者模式可以將
這兩者封裝在獨(dú)立的對象中使它們各自獨(dú)立地改變和復(fù)用。
14.模版方法:Template Method
定義一個操作的算法骨架旺罢，而將一些步驟延遲到子類中旷余，模版方法
使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟.
優(yōu)點(diǎn):
模板方法模式通過把不變的行為搬移到超類，去除了子類中的重復(fù)代碼扁达。
子類實(shí)現(xiàn)算法的某些細(xì)節(jié)正卧，有助于算法的擴(kuò)展。
通過一個父類調(diào)用子類實(shí)現(xiàn)的操作跪解，通過子類擴(kuò)展增加新的行為炉旷，符合“開放-封閉原則”。
缺點(diǎn):
每個不同的實(shí)現(xiàn)都需要定義一個子類，這會導(dǎo)致類的個數(shù)的增加窘行，設(shè)計更加抽象饥追。
適用場景:
在某些類的算法中，用了相同的方法罐盔，造成代碼的重復(fù)但绕。
控制子類擴(kuò)展，子類必須遵守算法規(guī)則惶看。
15.命令:Command
將一個請求封裝為一個對象捏顺，從而使你可用不同的請求對客戶進(jìn)行
參數(shù)化; 可以對請求排隊或請求日志，以及支持可撤銷的操作纬黎。
優(yōu)點(diǎn)：
- 1 他能較容易地設(shè)計一個命令隊列
- 2 在需要的情況下幅骄，可以較容易地將命令記入日志
- 3 允許接收請求的一方?jīng)Q定是否要否決請求
- 4 可以容易地實(shí)現(xiàn)對請求的撤銷和重做
- 5 由于加進(jìn)新的具體命令類不影響其他的類 因此新的具體命令類很容易
適用場景：
- 命令的發(fā)送者和命令執(zhí)行者有不同的生命周期。命令發(fā)送了并不是立即執(zhí)行莹桅。
- 命令需要進(jìn)行各種管理邏輯昌执。
- 需要支持撤消\重做操作（這種狀況的代碼大家可以上網(wǎng)搜索下，有很多诈泼，這里不進(jìn)行詳細(xì)解讀）懂拾。
16.狀態(tài):State
允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為，讓對象看起來似乎
修改了它的類铐达。
優(yōu)點(diǎn):
狀態(tài)模式將與特定狀態(tài)相關(guān)的行為局部化岖赋，并且將不同狀態(tài)的行為分割開來。
所有狀態(tài)相關(guān)的代碼都存在于某個ConcereteState中瓮孙，所以通過定義新的子類很容易地增加新的狀態(tài)和轉(zhuǎn)換唐断。
狀態(tài)模式通過把各種狀態(tài)轉(zhuǎn)移邏輯分不到State的子類之間，來減少相互間的依賴杭抠。
缺點(diǎn):
導(dǎo)致較多的ConcreteState子類
適用場景:
當(dāng)一個對象的行為取決于它的狀態(tài)脸甘，并且它必須在運(yùn)行時刻根據(jù)狀態(tài)改變它的行為時，就可以考慮使用狀態(tài)模式來偏灿。
一個操作中含有龐大的分支結(jié)構(gòu)丹诀，并且這些分支決定于對象的狀態(tài)。
17.職責(zé)鏈:Chain Of Responsibleity
使多個對象都有機(jī)會處理請求翁垂，從而避免請求的發(fā)送者和接收者之間
的耦合關(guān)系铆遭。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求 沿猜，直到有
一個對象處理它為止枚荣。
職責(zé)鏈模式的優(yōu)點(diǎn):
降低耦合度
可簡化對象的相互連接
增強(qiáng)給對象指派職責(zé)的靈活性
增加新的請求處理類很方便
職責(zé)鏈模式的缺點(diǎn):
不能保證請求一定被接收。
系統(tǒng)性能將受到一定影響啼肩，而且在進(jìn)行代碼調(diào)試時不太方便橄妆；可能會造成循環(huán)調(diào)用衙伶。
在以下情況下可以使用職責(zé)鏈模式：
有多個對象可以處理同一個請求，具體哪個對象處理該請求由運(yùn)行時刻自動確定呼畸。
在不明確指定接收者的情況下痕支，向多個對象中的一個提交一個請求。
可動態(tài)指定一組對象處理請求蛮原。
18.解釋器:Interpreter
給定一個語言，定義它的文法的一種表示另绩，并定義一個解釋器儒陨，這個
解釋器，使用該表示來解釋語言中的句子笋籽。
好處：
- 可以很容易地改變和拓展文法蹦漠，因?yàn)樵撃Ｊ绞褂妙?/li>
- 來表示文法規(guī)則，你可使用集成來改變或拓展該
- 文法车海。也比較容易實(shí)現(xiàn)文法笛园，因?yàn)槎x抽象語法樹
- 中各個節(jié)點(diǎn)的類的實(shí)現(xiàn)大體類似，這些類都易于直接編寫侍芝。
不足: - 解釋器模式為文法中的每一條規(guī)則至少定義了一個類
- 因此包含許多規(guī)則的文法可能難以管理和維護(hù)
- 建議當(dāng)文法非常復(fù)雜時研铆，使用其他的技術(shù)如語法
- 分析程序或編譯器生成器來處理
適用環(huán)境：
①重復(fù)發(fā)生的問題可以使用解釋器模式
②一個簡單語法需要解釋的場景
19.中介者:Mediator
用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯
式地相互引用州叠，從而使其耦合松散棵红，而且可以獨(dú)立地改變它們之間的交互。
中介者模式優(yōu)點(diǎn):
- 1.Mediator的出現(xiàn)減少了各個 Colleague 的耦合咧栗，使得
- 可以獨(dú)立地改變和復(fù)用各個 Colleague類和Mediator
- 2由于把對象如何協(xié)作進(jìn)行了抽象逆甜，將中介作為一個獨(dú)立的
- 概念并將其封裝在了一個對象中，這樣關(guān)注的對象就從對象
- 各自本身的行為轉(zhuǎn)移到它們之間的交互上來致板，也就是站在一個更宏觀的角度去看待系統(tǒng)
缺點(diǎn): - 由于ConcreteMediator 控制了集中化交煞，于是就把交互復(fù)雜性
- 變?yōu)榱酥薪檎叩膹?fù)雜性，這就使得中介者會變得比任何一個ConcreteColleague 都復(fù)雜
使用終結(jié)者模式的場合:
1.一組定義良好的對象斟或，現(xiàn)在要進(jìn)行復(fù)雜的通信素征。
2.定制一個分布在多個類中的行為，而又不想生成太多的子類缕粹。
中介對象主要是用來封裝行為的稚茅，行為的參與者就是那些對象，但是通過中介者平斩，這些對象不用相互知道亚享。
20.訪問者:Visitor
一個作用于某對象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變元素
的類的前提下定義作用于這些元素的新操作绘面。
優(yōu)點(diǎn):
1欺税、使得新增新的訪問操作變得更加簡單侈沪。
2、能夠使得用戶在不修改現(xiàn)有類的層次結(jié)構(gòu)下晚凿，定義該類層次結(jié)構(gòu)的操作亭罪。
3、將有關(guān)元素對象的訪問行為集中到一個訪問者對象中歼秽，而不是分散搞一個個的元素類中应役。
缺點(diǎn):
1、增加新的元素類很困難燥筷。在訪問者模式中箩祥，每增加一個新的元素類都意味著要在抽象訪問者角色中
增加一個新的抽象操作，并在每一個具體訪問者類中增加相應(yīng)的具體操作肆氓，違背了“開閉原則”的要求袍祖。
2、破壞封裝谢揪。當(dāng)采用訪問者模式的時候蕉陋，就會打破組合類的封裝。
3拨扶、比較難理解凳鬓。貌似是最難的設(shè)計模式了。
模式適用場景:
1屈雄、對象結(jié)構(gòu)中對象對應(yīng)的類很少改變村视，但經(jīng)常需要在此對象結(jié)構(gòu)上定義新的操作。
2酒奶、需要對一個對象結(jié)構(gòu)中的對象進(jìn)行很多不同的并且不相關(guān)的操作蚁孔，而需要避免讓
這些操作“污染”這些對象的類，也不希望在增加新操作時修改這些類惋嚎。
21.策略:Strategy
定義一系列算法杠氢，把它們一個個封裝起來，并且使它們可替換另伍。本模
式使得算法可獨(dú)立于使用它的客戶而變化鼻百。
優(yōu)點(diǎn):
策略類之間可以自由切換，由于策略類實(shí)現(xiàn)自同一個抽象摆尝，所以他們之間可以自由切換温艇。
易于擴(kuò)展，增加一個新的策略對策略模式來說非常容易堕汞，基本上可以在不改變原有代碼的基礎(chǔ)上進(jìn)行擴(kuò)展勺爱。
避免使用多重條件.
缺點(diǎn):
維護(hù)各個策略類會給開發(fā)帶來額外開銷
必須對客戶端（調(diào)用者）暴露所有的策略類
模式適用場景:
1）許多相關(guān)的類僅僅是行為有異。
2）需要使用一個算法的不同變體讯检。
3）算法使用客戶不應(yīng)該知道的數(shù)據(jù)琐鲁。
4）一個類定義了多種行為 , 并且這些行為在這個類的操作中以多個條件語句的形式出現(xiàn)卫旱。
22.備忘錄:Memento
不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)围段，并在該對象之外
保持這個狀態(tài)顾翼。這樣以后就可將該對象恢復(fù)到原先保存的狀態(tài)。
使用備忘錄模式的好處：
1）有時一些發(fā)起人對象的內(nèi)部信息必須保存在發(fā)起人對象以外的地方奈泪，但是必須要由發(fā)起人對象自己讀取适贸，
這時使用備忘錄模式可以把復(fù)雜的發(fā)起人內(nèi)部信息對其他的對象屏蔽起來，從而可以恰當(dāng)?shù)乇３址庋b的邊界段磨。
2）本模式簡化了發(fā)起人類取逾。發(fā)起人不再需要管理和保存其內(nèi)部狀態(tài)的一個個版本，客戶端可以自
行管理他們所需要的這些狀態(tài)的版本苹支。
3）當(dāng)發(fā)起人角色的狀態(tài)改變的時候，有可能這個狀態(tài)無效误阻，這時候就可以使用暫時存儲起來的備忘錄將狀態(tài)復(fù)原债蜜。
使用備忘錄模式的缺點(diǎn)：
1）如果發(fā)起人角色的狀態(tài)需要完整地存儲到備忘錄對象中，那么在資源消耗上面?zhèn)渫泴ο髸馨嘿F究反。
2）當(dāng)負(fù)責(zé)人角色將一個備忘錄存儲起來的時候寻定，負(fù)責(zé)人可能并不知道這個狀態(tài)會占用多大的存儲空間，
從而無法提醒用戶一個操作是否很昂貴精耐。
使用備忘錄模式的場合：
1）功能比較復(fù)雜的狼速，但是需要維護(hù)或記錄屬性歷史的類。
2）需要保存的屬性只是眾多屬性的一小部分時卦停。
23.迭代器:Iterator
提供一種方法順序訪問一個聚合對象中各個元素向胡，而又不需暴露該對
象的內(nèi)部表示。
迭代器模式的優(yōu)點(diǎn)有：
1惊完、它支持以不同的方式遍歷一個聚合對象僵芹。
2、迭代器簡化了聚合類小槐。
3拇派、在同一個聚合上可以有多個遍歷。
4凿跳、在迭代器模式中件豌，增加新的聚合類和迭代器類都很方便，無須修改原有代碼控嗜。
迭代器模式的缺點(diǎn)：
對于比較簡單的遍歷（像數(shù)組或者有序列表）茧彤，使用迭代器方式遍歷較為繁瑣
迭代器模式的適用場景:
1、訪問一個聚合對象的內(nèi)容而無須暴露它的內(nèi)部表示躬审。
2棘街、需要為聚合對象提供多種遍歷方式蟆盐。
3、為遍歷不同的聚合結(jié)構(gòu)提供一個統(tǒng)一的接口遭殉。
