附录 3
Java 的思考
抽象过程
所有编程语言都提供抽象(abstraction)机制。可以认为,你所能够解决
的问题的复杂性直接取决于抽象的类型和质量。我所谓的“类型”是指“你所
抽象的是什么?”汇编语言是对底层机器的小型抽象。接着出现的许多所谓
“命令式(Imperative)”语言(诸如 FORTRAN、BASIC、C 等)都是对汇编语言
的抽象。这些语言在汇编语言之上有了大幅的改进,但是它们所作的主要
抽象仍要求你在解决问题时要基于计算机的结构,而不是基于你试图要解
决的问题的结构来考量。程序员必须建立在机器模型(Machine Model)(位于
你对问题建模所作的解空间(Solution)内,例如计算机)和实际待解决问题模
型(Problem Model)(位于问题所在的问题空间(Problem Space)内)之间的关联。
建立这种映射(Mapping)是费力的,而且它不属于编程语言的内在性质,这
使得程序难以编写,并且维护代价高昂。由此,产生了完整的“编程方法
(Programming Method)”产业。
另一种对机器建模的方式就是对待解决问题建模。早期的编程语言,
诸如 LISP 和 APL 都选择世界的某种特定视图(分别对应于“所有问题最终都
是列表(List)”或者“所有问题都是算法形式的(algorithmic)”)。PROLOG 则将
所有文图转换成为决策链(Chain of decisions)。此外还产生了基于约束条件
(constraint-based)编程的语言(后者被证明限制性过强)。这些方式对于它们
被设计时所瞄准要解决的特定类型的问题都是不错的解决方案,但是一旦
超出其特定领域,它们就力不从心了。
面向对象方式(Object-oriented approach)通过向程序员提供用来表示在
问题空间中的元素的工具而更进一步。这种表示方式具有足够的概括性,
使得程序员不会受限于任何特定类型的问题。我们将问题空间中的元素及
其在解空间中的表示成为“对象(Object)”。(你还需要一些无法类比为问题空
间元素的对象)。这是一种更灵活和更强有力的语言抽象。所以,OOP 允许
以问题的形式来描述问题,而不是以执行解决方案的计算机的形式来描述