标签：blog http io ar 使用 sp on 2014 log
从这一章节开始我们将正式进入WebGIS的工具栏中相关功能的设计和实现。我们以ArcMap中的工具栏中的基本工具为模板，将其中的放大、缩小、平移、全图、清除、定位、I查询、距离量测、面积量测在WebGIS中进行实现。
这里，我先跟大家说一个基本的概念。我们一般将工具分为Command和Tool。所谓command是指该工具被调用后，生效一次即终止。而Tool则是当被调用后，持续有效，直至终止该工具或者切换工具。
按照这个理论，我们可以将工具栏中的基本工具分一下类：
Command：全图、清除、定位。
Tool：放大、缩小、平移、I查询、距离量测、面积量测。
对工具栏中的内部控制哪一个工具该实例化以及生效，可以通过策略模式+工厂模式。但是为了简单，策略模式就足以了。
但是，因为工具栏中有诸多Tool型的工具，简单的策略模式是无法满足Tool终止和切换的需求的。这里我们将用到23种设计模式中的一种：命令模式。
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://home.cnblogs.com/u/naaoveGIS/
标签：blog http io ar 使用 sp on 2014 log
原文地址：http://www.cnblogs.com/naaoveGIS/p/4066959.html
