一、 引言 ![]() ![]() ![]() ![]() 二、 定義與結(jié)構(gòu) 迭代器(Iterator)模式,又叫做游標(biāo)(Cursor)模式。GOF給出的定義為:提供一種方法訪(fǎng)問(wèn)一個(gè)容器(container)對(duì)象中各個(gè)元素,而又不需暴露該對(duì)象的內(nèi)部細(xì)節(jié)。 從定義可見(jiàn),迭代器模式是為容器而生。很明顯,對(duì)容器對(duì)象的訪(fǎng)問(wèn)必然涉及到遍歷算法。你可以一股腦的將遍歷方法塞到容器對(duì)象中去;或者根本不去提供什么遍歷算法,讓使用容器的人自己去實(shí)現(xiàn)去吧。這兩種情況好像都能夠解決問(wèn)題。 然而在前一種情況,容器承受了過(guò)多的功能,它不僅要負(fù)責(zé)自己“容器”內(nèi)的元素維護(hù)(添加、刪除等等),而且還要提供遍歷自身的接口;而且由于遍歷狀態(tài)保存的問(wèn)題,不能對(duì)同一個(gè)容器對(duì)象同時(shí)進(jìn)行多個(gè)遍歷。第二種方式倒是省事,卻又將容器的內(nèi)部細(xì)節(jié)暴露無(wú)遺。 而迭代器模式的出現(xiàn),很好的解決了上面兩種情況的弊端。先來(lái)看下迭代器模式的真面目吧。 迭代器模式由以下角色組成: 1) 迭代器角色(Iterator):迭代器角色負(fù)責(zé)定義訪(fǎng)問(wèn)和遍歷元素的接口。 2) 具體迭代器角色(Concrete Iterator):具體迭代器角色要實(shí)現(xiàn)迭代器接口,并要記錄遍歷中的當(dāng)前位置。 3) 容器角色(Container):容器角色負(fù)責(zé)提供創(chuàng)建具體迭代器角色的接口。 4) 具體容器角色(Concrete Container):具體容器角色實(shí)現(xiàn)創(chuàng)建具體迭代器角色的接口——這個(gè)具體迭代器角色于該容器的結(jié)構(gòu)相關(guān)。 迭代器模式的類(lèi)圖如下:
從結(jié)構(gòu)上可以看出,迭代器模式在客戶(hù)與容器之間加入了迭代器角色。迭代器角色的加入,就可以很好的避免容器內(nèi)部細(xì)節(jié)的暴露,而且也使得設(shè)計(jì)符號(hào)“單一職責(zé)原則”。 注意,在迭代器模式中,具體迭代器角色和具體容器角色是耦合在一起的——遍歷算法是與容器的內(nèi)部細(xì)節(jié)緊密相關(guān)的。為了使客戶(hù)程序從與具體迭代器角色耦合 的困境中脫離出來(lái),避免具體迭代器角色的更換給客戶(hù)程序帶來(lái)的修改,迭代器模式抽象了具體迭代器角色,使得客戶(hù)程序更具一般性和重用性。這被稱(chēng)為多態(tài)迭 代。 三、 舉例 由于迭代器模式本身的規(guī)定比較松散,所以具體實(shí)現(xiàn)也就五花八門(mén)。我們?cè)诖藘H舉一例,根本不能將實(shí)現(xiàn)方式一一呈現(xiàn)。因此在舉例前,我們先來(lái)列舉下迭代器模式的實(shí)現(xiàn)方式。 1.迭代器角色定義了遍歷的接口,但是沒(méi)有規(guī)定由誰(shuí)來(lái)控制迭代。在Java collection的應(yīng)用中,是由客戶(hù)程序來(lái)控制遍歷的進(jìn)程,被稱(chēng)為外部迭代器;還有一種實(shí)現(xiàn)方式便是由迭代器自身來(lái)控制迭代,被稱(chēng)為內(nèi)部迭代器。外部 迭代器要比內(nèi)部迭代器靈活、強(qiáng)大,而且內(nèi)部迭代器在java語(yǔ)言環(huán)境中,可用性很弱。 2.在迭代器模式中沒(méi)有規(guī)定誰(shuí)來(lái)實(shí)現(xiàn)遍歷算法。 好像理所當(dāng)然的要在迭代器角色中實(shí)現(xiàn)。因?yàn)榧缺阌谝粋€(gè)容器上使用不同的遍歷算法,也便于將一種遍歷算法應(yīng)用于不同的容器。但是這樣就破壞掉了容器的封裝 ——容器角色就要公開(kāi)自己的私有屬性,在java中便意味著向其他類(lèi)公開(kāi)了自己的私有屬性。 那我們把它放到容器角色里來(lái)實(shí)現(xiàn)好了。這樣迭代器角色就被架空為僅僅存放一個(gè)遍歷當(dāng)前位置的功能。但是遍歷算法便和特定的容器緊緊綁在一起了。 而在Java Collection的應(yīng)用中,提供的具體迭代器角色是定義在容器角色中的內(nèi)部類(lèi)。這樣便保護(hù)了容器的封裝。但是同時(shí)容器也提供了遍歷算法接口,你可以擴(kuò)展自己的迭代器。 好了,我們來(lái)看下Java Collection中的迭代器是怎么實(shí)現(xiàn)的吧。 ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() 至于迭代器模式的使用。正如引言中所列那樣,客戶(hù)程序要先得到具體容器角色,然后再通過(guò)具體容器角色得到具體迭代器角色。這樣便可以使用具體迭代器角色來(lái)遍歷容器了…… 四、 實(shí)現(xiàn)自己的迭代器 在實(shí)現(xiàn)自己的迭代器的時(shí)候,一般要操作的容器有支持的接口才可以。而且我們還要注意以下問(wèn)題: 在迭代器遍歷的過(guò)程中,通過(guò)該迭代器進(jìn)行容器元素的增減操作是否安全呢? 在容器中存在復(fù)合對(duì)象的情況,迭代器怎樣才能支持深層遍歷和多種遍歷呢? 以上兩個(gè)問(wèn)題對(duì)于不同結(jié)構(gòu)的容器角色,各不相同,值得考慮。 五、 適用情況 由上面的講述,我們可以看出迭代器模式給容器的應(yīng)用帶來(lái)以下好處: 1) 支持以不同的方式遍歷一個(gè)容器角色。根據(jù)實(shí)現(xiàn)方式的不同,效果上會(huì)有差別。 2) 簡(jiǎn)化了容器的接口。但是在java Collection中為了提高可擴(kuò)展性,容器還是提供了遍歷的接口。 3) 對(duì)同一個(gè)容器對(duì)象,可以同時(shí)進(jìn)行多個(gè)遍歷。因?yàn)楸闅v狀態(tài)是保存在每一個(gè)迭代器對(duì)象中的。 由此也能得出迭代器模式的適用范圍: 1) 訪(fǎng)問(wèn)一個(gè)容器對(duì)象的內(nèi)容而無(wú)需暴露它的內(nèi)部表示。 2) 支持對(duì)容器對(duì)象的多種遍歷。 3) 為遍歷不同的容器結(jié)構(gòu)提供一個(gè)統(tǒng)一的接口(多態(tài)迭代)。 六、 總結(jié) 迭代器模式在我們的應(yīng)用中很廣泛,希望本文能幫助你理解它。如有不對(duì)之處,還請(qǐng)不吝指正。 |
|
來(lái)自: 漂在北方的狼 > 《設(shè)計(jì)模式》