this.req=new XMLHttpRequest();

        }

        else if (window.ActiveXObject)

        {

            this.req=new ActiveXObject("Microsoft.XMLHTTP");

        }

这里的一个IF语句帮助我们实现了跨平台性，它便是一个Adapter。在这里，我们通过一点来自动适应各种平台的变化。我们的程序代码期待一个统一的创建XHR的接口。这段代码实现了这个接口，并且通过委托（delegate）的机制，自动帮我们用各种方法在各种不同的平台下实例化一个XHR对象。

想象一下，在不远的未来，有一种Xbrower出现，并且非常红火，值得我们兼容。我们只要改变我们的Adapter，就可以适应该变化。而我们其他的客户端代码都不需要修改，岂不很好吗？

2、          Facade模式

当你需要用XHR对象向服务器请求数据的时候，你总是会很痛苦的执行一连串操作，仅仅是为了请求一次数据：

1、          建立XHR对象

2、          注册callback函数

3、          用open方法设置请求方式，地址，模式

4、          用send发送请求

5、          监视请求的状态，当达到某一特定状态时，执行某项特殊功能。。。

天，好复杂，可是为什么我们要不断地重复自己呢？

上面的ContentLoader类就可以很好的屏蔽这些复杂性。当你想要从服务器端获得一些数据的时候，你关心的是服务器端的数据，而不是这整个复杂的过程。通过应用上面的这个ContentLoader类，你可以很轻松的用两行代码就获得数据。

var myRequest = new CGIAJAX.util.ContentLoader(url, refreshTalbe);

myRequest.loadXMLDoc();

可以看到，实际上ContentLoader类就是一个简单的接口，它将整个复杂的接口简单化、统一化。如此一来，我们就可以DRY了。当然，ContentLoader类并不会使我们的灵活性有所降低。如果你需要的话，你还是可以直接调用浏览器所提供的XHR接口的。可是大多数时候，我们只需要用ContentLoader类就可以很好的完成任务了。

再想象一下。假如说未来W3C将XHR作为标准，并且扩充了XHR接口的功能，那么我们怎么办？很可能扩充功能的代价就是接口的变化或者接口调用顺序的变化。如果我们没有应用Facade模式，我们会怎样？逐个修改代码中每一个用到XHR的地方？知道一切运转起来看似没有问题？或者我们现在就应用Facade模式，到时候，我们就可以轻松的修改一下Facade模式所涉及的接口内容，然后跑去看NBA了，不是吗？

五、     警惕Ajax开发！

为何要警惕Ajax开发？

众所周知，由于Ajax导致Web开发模式上的变化，将会导致客户端代码的激增，由量变变成质变。而且最重要的是，Ajax现在所用到的各种技术，很大一部分都还没有成为标准，或者刚刚成为标准。这就意味着，这些东西会在未来的一段时间内，频繁变化。如果我们应用程序设计时，对该方面的变化有所准备，那么到头来痛苦的只有我们自己。

在Ajax开发中应用OO模式以及OO原则，最重要的并不是炫耀某种技术，而是期望这种已被证明的强大技术能够为我们的开发带来根本上的好处。

上一页  [1] [2] [3] [4] [5] [6]