文章版權由做者李曉暉和博客園共有,若轉載請於明顯處標明出處:http://www.cnblogs.com/naaoveGIS/。設計模式
從這一章節開始咱們將正式進入WebGIS的工具欄中相關功能的設計和實現。咱們以ArcMap中的工具欄中的基本工具爲模板,將其中的放大、縮小、平移、全圖、清除、定位、I查詢、距離量測、面積量測在WebGIS中進行實現。微信
這裏,我先跟你們說一個基本的概念。咱們通常將工具分爲Command和Tool。所謂command是指該工具被調用後,生效一次即終止。而Tool則是當被調用後,持續有效,直至終止該工具或者切換工具。工具
按照這個理論,咱們能夠將工具欄中的基本工具分一下類:設計
Command:全圖、清除、定位。3d
Tool:放大、縮小、平移、I查詢、距離量測、面積量測。日誌
對工具欄中的內部控制哪個工具該實例化以及生效,能夠經過策略模式+工廠模式。可是爲了簡單,策略模式就足以了。對象
可是,由於工具欄中有諸多Tool型的工具,簡單的策略模式是沒法知足Tool終止和切換的需求的。這裏咱們將用到23種設計模式中的一種:命令模式。blog
GOF中給出了命令模式的使用場景:接口
A、當一個應用程序調用者與多個目標對象之間存在調用關係時,而且目標對象之間的操做很相似的時候。隊列
B、當一個目標對象內部的方法調用太複雜,或者內部的方法須要協做才能完成對象的某個特色操做時(做者注:好比要對行爲進行「記錄、撤銷/重作、事務」等處理)。
C、調用者調用目標對象後,須要回調一些方法。
分析咱們Tool的使用,均是與鼠標事件有關,好比:mouseDown、mouseUp、mouseMove、mouseOut、mouseClick、mouseWheel等。是知足命令模式使用的場景A的,而場景B和C也是頗有可能會在咱們使用中觸發的。
綜上分析,進一步證實咱們這裏選着使用命令模式是正確的。
這裏我先給出命令模式的UML圖:
以上UML圖中涉及到五個角色,它們分別是:
客戶端(Client)角色:建立一個具體命令(ConcreteCommand)對象並肯定其接收者。
命令(Command)角色:聲明瞭一個給全部具體命令類的抽象接口。
具體命令(ConcreteCommand)角色:定義一個接收者和行爲之間的弱耦合;實現execute()方法,負責調用接收者的相應操做。execute()方法一般叫作執行方法。
請求者(Invoker)角色:負責調用命令對象執行請求,相關的方法叫作行動方法。
接收者(Receiver)角色:負責具體實施和執行一個請求。任何一個類均可以成爲接收者,實施和執行請求的方法叫作行動方法。
在實際運用中 ,咱們常常會對GOF給出的設計模式中的UML稍做變通,以便簡化開發或者便於開發。這裏,咱們也對以上的UML作了些許變化。
我這裏先給出變化後的UML圖。
由於全部的命令都是針對於Map的,因此沒有將Command設計成接口,而是讓他變成一個抽象類,這樣有兩個好處:
A.使Map變爲屬性,直接讓Command關聯上Map。
B.能夠在類中完成部分公用代碼,好比mouseWheel()方法所涉及的功能是全部的命令類公用的。
而且捨棄了Receiver這樣的接受者的編寫,而是直接將Receiver中所涉及到的方法編寫移到每個ConcreteCommand中了。這樣能夠減小類的個數。
命令的切換由相似於Invoke類的MapNavigation類中的setMapCommand來控制。
A.更鬆散的耦合:
命令模式使得發起命令的對象——客戶端,和具體實現命令的對象——接收者對象徹底解耦,也就是說發起命令的對象徹底不知道具體實現對象是誰,也不知道如何實現。
B.更動態的控制:
命令模式把請求封裝起來,能夠動態地對它進行參數化、隊列化和日誌化等操做,從而使得系統更靈活。
C.很天然的複合命令:
命令模式中的命令對象可以很容易地組合成複合命令,也就是宏命令,從而使系統操做更簡單,功能更強大。
D.更好的擴展性:
因爲發起命令的對象和具體的實現徹底解耦,所以擴展新的命令就很容易,只須要實現新的命令對象,而後在裝配的時候,把具體的實現對象設置到命令對象中,而後就可使用這個命令對象,已有的實現徹底不用變化。
在這一章裏,咱們介紹了命令模式的設計和實現思路。在接下來的章節裏,咱們將針對我提到的工具欄中的基本工具:放大、縮小、平移、全圖、清除、定位、I查詢、距離量測、面積量測,的設計和實現進行逐個講解。歡迎你們持續關注。
-----歡迎轉載,但保留版權,請於明顯處標明出處:http://www.cnblogs.com/naaoveGIS/
若是您以爲本文確實幫助了您,能夠微信掃一掃,進行小額的打賞和鼓勵,謝謝 ^_^