1.1 抽象过程
2009年08月27日 星期四 13:11
第一章 对象引论
“我们之所以将自然界分解，组织成为各种概念，并总结出其重要性，主要是因为我们知道我们的语言社区所共同持有的，并以我们的语言的形式所固定下来的一种约定…除非赞成这个约定中所颁布的有关数据的组织和分类的内容，否则我们根本无法交谈。”
BenjaminLee Whorf(1897-1941)
计算机革命起源于机器，因此，编程语言的起源也始于对机器的模仿趋近。但是，计算机并非只是机器那么简单。计算机是头脑延伸的工具（就象 Steven Jobs 常喜欢说的“头脑的自行车”一样），同时还是一种不同类型的表达媒体。因此，这种工具看起来已经越来越不像机器，而更像我们头脑的一部分，以及一种诸如写作、绘画、雕刻、动画、电影等的表达形式一样。面向对象程序设计（Object-oriented Programming, OOP）便是这种以计算机作为表达媒体的大潮中的一波。本章将向您介绍包括开发方法概述在内的 OOP 的基本概念。本章，乃至本书中，都假设您在过程型编程语言（Procedural Programming Language）方面已经具备了某些经验，当然不一定必须是 C。如果您认为您在阅读本书之前还需要在编程以及 C 语法方面多做些准备，您可以研读本书所附的培训光盘“Java 基础（Foundations for Java）”。本章介绍的是背景性的和补充性的材料。许多人在没有了解面向对象程序设计的全貌之前，感觉无法轻松自在地从事此类编程。因此，此处将引入众多的概念，以期助您建立对OOP 的扎实全面的见解。然而，还有些人可能直到在看到运行机制的某些实例之前，都无法了解面向对象程序设计的全貌，这些人如果没有代码在手，就会陷于困境并最终迷失方向。如果您属于后面的这个群体，并且渴望尽快获取 Java 语言的细节，那么您可以越过本章--在此处越过本章并不会妨碍您编写程序和学习语言。但是，您最终还是会回到本章来填补您的知识，这样您才能够了解到为什么对象如此重要，以及怎样使用对象来进行设计。
抽象过程
所有编程语言都提供抽象（abstraction）机制。可以认为，你所能够解决的问题的复杂性直接取决于抽象的类型和质量。我所谓的“类型”是指“你所抽象的是什么？”汇编语言是对底层机器的小型抽象。接着出现的许多所谓“命令式（Imperative）”语言（诸如 FORTRAN、BASIC、C 等）都是对汇编语言的抽象。这些语言在汇编语言之上有了大幅的改进，但是它们所作的主要抽象仍要求你在解决问题时要基于计算机的结构，而不是基于你试图要解决的问题的结构来考量。程序员必须建立在机器模型（Machine Model）（位于你对问题建模所在的解空间（Solution Space）内，例如计算机）和实际待解问题模型（Problem Model）（位于问题所在的问题空间（Problem Space）内）之间的关联。建立这种映射（Mapping）是费力的，而且它不属于编程语言的内在性质，这使得程序难以编写，并且维护代价高昂。由此，产生了完整的“编程方法（Programming Method）”产业。
另一种对机器建模的方式就是对待解决问题建模。早期的编程语言，诸如 LISP 和 APL 都选择世界的某种特定视图（分别对应于“所有问题最终都是列表（List）”或者“所有问题都是算法形式的（algorithmic）”）。PROLOG 则将所有问题都转换成为决策链（Chain of decisions）。此外还产生了基于约束条件（constraint-based）编程的语言和专门通过对图形符号操作来实现编程的语言（后者被证明限制性过强）。这些方式对于它们被设计时所瞄准要解决的特定类型的问题都是不错的解决方案，但是一旦超出其特定领域，它们就力不从心了。
当你创建了一个对象之后，只要你需要它，它就一直存活着，但是在程序终止后，它无论如何都不能存活了。在某些场合，如果对象在程序非执行状态下仍然能够存活，并保存其相关信息，将非常有用。当你下一次重新启动程序时，这个对象能够重生，并且拥有与上一次程序执行时相同的信息。当然，你可以通过将信息写入文件或数据库中达到相同的效果，但是在“万物皆为对象”的精神下，能够将对象声明为持久的（persistent），并让语言系统为你处理所有细节，不是非常方便吗？
Web 是什么?
Web 一词乍一看有点神秘，就象“网上冲浪（surfing）”、“表现（presence）”、“主页（homepage）”一样。我们回头审视它的真实面貌有助于对它的理解，但是要这么做就必须先理解客户/服务器（client/server）系统，它使计算技术中另一个充满了诸多疑惑的话题。
客户/服务器计算技术
客户/ 服务器系统的核心思想是：系统具有一个中央信息存储池（ central repository ofinformation），用来存储某种数据，它通常存在于数据库中，你可以根据需要将它分发给某个人员或机器集群。客户/服务器概念的关键在于信息存储池的位置集中于中央，这使得它可以被修改，并且这些修改将被传播给信息消费者。总之，信息存储池是用于分发信息的软件，信息与软件的宿主机器（或机器的集群）被称为服务器（server）。宿主于远程机器上的软件与服务器进行通信，以获取信息、处理信息，然后将它们显示在被称为客户（client）的远程机器上。
客户机/服务器计算技术的基本概念并不复杂。问题在于你只有单一的服务器，却要同时为多个客户服务。通常，这都会涉及数据库管理系统，因此设计者“权衡”数据置于数据表（table）中的结构，以取得最优的使用效果。此外，系统通常允许客户在服务器中插入新的信息。这意味着你必须保证一个客户插入的新数据不会覆盖另一个客户插入的新数据，也不会在将其添加到数据库的过程中丢失（这被称为事务处理（transaction processing））。如果客户端软件发生变化，那么它必须被重新编译、调试并安装到客户端机器上，事实证明这比你想象中的要更加复杂与费力。如果想支持多种不同类型的计算机和操作系统，问题将更麻烦。最后还有一个最重要的性能问题：可能在任意时刻都有成百上千的客户向服务器发出请求，那么随便多么小的延迟都会产生重大影响。为了将延迟最小化，程序员努力地减轻处理任务的负载，通常是分散给客户端机器处理，但有时也会使用所谓“中间件（middleware）”将负载分散给在服务器端的其它机器。（中间件也被用来提高可维护性（maintainability））
分发信息这个简单思想的复杂性实际上是有很多不同层次的，这使得整个问题可能看起来高深莫测得让人绝望。但是它仍然至关重要：算起来客户/服务器计算技术大概占了所有程序设计行为的一半，从制定订单、信用卡交易到包括股票市场、科学计算、政府、个人在内的任意类型的数据分发。过去我们所作的，都是针对某个问题发明一个单独的解决方案，所以每一次都要发明一个新的方案。这些方案难以开发并难以使用，而且用户对每一个方案都要学习新的接口。因此，整个客户/服务器问题需要彻底地解决。
Web 就是一台巨型服务器
Web 实际上就是一个巨型客户/服务器系统，但是比其稍微差一点，因为所有的服务器和客户机都同时共存于同一个网络中。你不需要了解这些，因为你所要关心的只是在某一时刻怎样连接到一台服务器上，并与之进行交互（即便你可能要满世界地查找你想要的服务器）。最初只有一种很简单的单向过程（one-way process）：你对某个服务器产生一个请求，然后它返回给你一个文件，你的机器（也就是客户机）上的浏览器软件根据本地机器的格式来解读这个文件。但是很快人们就希望能够做得更多，而不仅仅是从服务器传递会页面。他们希望实现完整的客户/服务器能力，使得客户可以将信息反馈给服务器。例如，在服务器上进行数据库查找、将新信息添加到服务器以及下订单（这需要比原始系统提供的安全性更高的安全保障）。这些变革，正是我们在 Web 发展过程中一直目睹的。
Web 浏览器是向前跨进的一大步，它包含了这样的概念：一段信息不经修改就可以在任意型号的计算机上显示。然而，浏览器仍然相当原始，很快就因为加诸于其上的种种需要而陷入困境。浏览器并不具备显著的交互性，而且它趋向于使服务器和 Internet 阻塞，因为在任何时候，只要你需要完成通过编程来实现的任务，就必须将信息发回到服务器去处理。这使得即便是发现你的请求中的拼写错误也要花去数秒甚至是数分钟的时间。因为浏览器只是一个视图工具，因此它甚至不能执行最简单的计算任务。（另一方面，它却是安全的，因为它在你的本地机器上不会执行任何程序，而这些程序有可能包含 bug 和病毒。）为了解决这个问题，人们采用了各种不同的方法。首先，图形标准得到了增强，使得在浏览器中可以播放质量更好的动画和视频。剩下的问题通过引入在客户端浏览器中运行程序的能力就可以解决。这被称为“客户端编程（client-side programming）”。
客户端编程
Web 最初的“服务器-浏览器”设计是为了能够提供交互性的内容，但是其交互性完全由服务器提供。服务器产生静态页面，提供给只能解释并显示它们的客户端浏览器。基本的 HTML（HyperText Markup Language，超文本标记语言）包含有简单的数据收集机制：文本输入框（text-entry box）、复选框（check box）、单选框（radio box）、列表（list）和下拉式列表（drop-down list）等，以及只能被编程用来实现复位（reset）表单上的数据或提交（submit）表单上的数据给服务器的按钮。这种提交动作传递给所有的 Web 服务器都提供的通用网关接口（common gateway interface，CGI）。提交内容会告诉 CGI 应该如何处理它。最常见的动作就是运行一个在服务器中通常被命名为“cgi-bin”的目录下的一个程序。（当你点击了网页上的按钮时，如果你观察你的浏览器窗口顶部的地址，有时你可以看见“cgi-bin”的字样混迹在一串冗长不知所云的字符中。）几乎所有的语言都可以用来编写这些程序，Perl 已经成为了最常见的选择，因为它被设计用来处理文本，并且解释型语言，因此无论服务器的处理器和操作系统如何，它都可以被安装于其上。
当今许多有影响力的网站都是完全构建于 CGI 之上的，实际上你几乎可以通过 CGI 做任何事。然而，构建于 CGI 程序之上的网站可能会迅速变得过于复杂而难以维护，并同时产生响应时间过长的问题。CGI 程序的响应时间依赖于必须发送的数据量的大小，以及服务器和Internet 的负载，此外，CGI 程序的初始化也相当慢。Web 的最初设计者们并没有预见到网络带宽（bandwidth）被人们开发的各种应用迅速耗尽。例如，任何形式的动态图形处理几乎都不可能被连贯地执行，因为图形交互格式（graphic interchange format，GIF）的文件对每一种版本的图形都必须在服务器端创建，并发送给客户端。再比如，你肯定处理过像验证输入表单那样简单的事情：你按下网页上的提交（Submit）按钮；数据被封装发送回服务器；服务器启动一个 CGI 程序来检查发现错误，并将错误组装为一个用来通知你的 HTML 页面，然后将这个页面发回给你；你之后必须回退一个页面，然后重新再试。这个过程不仅很慢，而且不太优雅。
问题的解决方法就是客户端编程（client-side programming）。大多数运行 web 浏览器的机器都是能够执行大型任务的强有力的引擎。在使用原始的静态 HTML 方式的情况下，它们只是空闲地愣在那里，等着服务器送来下一个页面。客户端编程意味着 Web 浏览器被用来执行任何它可以完成的工作，使得返回给用户的结果更加迅捷，而且使得你的网站更加具有交互性。客户端编程的问题是：它与通常意义上的编程十分不同，参数几乎相同，而平台却不同。Web 浏览器就象一个功能受限的操作系统。当然，你仍然的编写程序，而且还得处理那些令人头晕眼花的成堆的问题，并以客户端编程的方式来产生解决方案。本节剩下的部分将带你纵览有关客户端编程的话题和方式。
