软件框架设计的艺术这本书只适用于Java_软件框架设计的艺术这本书只适用于Java试读-查字典图书网
查字典图书网
当前位置: 查字典 > 图书网 > 设计 > 软件框架设计的艺术 > 这本书只适用于Java

软件框架设计的艺术——这本书只适用于Java

NetBeans是一个使用Java语言开发的IDE框架,我的大部分与API有关的知识都是从这个项目中学到的。如果由我来回答这个问题:“这本书是否有益于那些非Java的开发?”那么答案仍然是肯定的。对于如何评价API设计是否良好,本书给出了很多准则,这些准则同样适用于其他的编程语言。本书中的一些议题,例如:开发API的原因,编写具有良好结构的文档的规则和动机,还有那些关于向后兼容的原则。这些内容都可以适用于多种编程语言,包括C、FORTRAN、Perl、Python和Haskell①。 当然,涉及细节的时候,就不得不提到Java语言的具体特性。要知道,Java首先是一种面向对象的语言。为面向对象的语言设计API的时候,像继承、虚方法②和封装这些特性都必须加以考虑。因此,本书给出的一些原则更适用于一些特定的面向对象语言,如C+ +、Python或Java,至于C或FORTRAN这些面向过程的语言,虽然不错,但已经有点古老了,不再适用本书中的原则。 Java是一种非常新的面向对象语言,它引入了垃圾收集器。当前,业界已经普遍接受了Java,说明即使在产品的正式运行环境下,垃圾收集器也是可用的且有益的。但在Java语言出现之前,业界更倾向那种自行管理内存的传统方式,如C、C++都是采用这种方式来管理内存,开发人员需要明确地声明如何去申请和释放内存。当时也有一些语言,像Smalltalk或Ada,它们使用了垃圾收集器,但它们都被当作实验品,没有几个软件开发商敢冒着这样大的风险去使用它们来开发软件。Java却从根本上扭转了这个现象。目前,可以说,一个基于内存自动管理系统的语言可以用来编写高性能的程序。大多数的软件工程师都已经普遍接受了这个观点,而不像以往只会取笑或者害怕使用这种基于内存自动管理的语言。一个能够自动管理内存的语言,会对你写的API有所要求。比如说,Java只能通过malloc一样的构造函数来分配对象,而不是像C一样,需要对应地释放API。而且Java中,其内存的释放无须程序员关注。所以本书中给出的一些意见或者做法更适用于带有垃圾收集器的语言,就是那种与Java相似、支持内存自动管理的语言。 Java还推广了虚拟机和动态编译技术的使用。Java的静态编译技术会将源代码编译成多个类文件。在代码真正运行的时候才去部署和连接这些文件。而这些编译好的类文件格式是不依赖于具体的处理器架构的,而应用程序最终运行于这个架构上。 以上所说的内容通过运行时环境实现,它不仅将分散的类文件连接③起来,还将指令转换成处理器可以识别的指令。从Java诞生之初,这一点就是Java与传统语言的相异之处。大家都知道,高性能程序不能通过虚拟机的解释来获得,像Fortran语言就要在不同的操作系统上分别进行编译,根据实际环境来生成相应的可执行汇编,这样才能够更好地利用硬件的各种特性来提高程序的运行性能。当时很多人,包括我自己在内,都认为只有使用C或C++才能编写出高性能的程序,而Java则不可能做到这一点。 然而,时间证明,基于虚拟机的编程语言具有一定的优势。例如跨平台,不管在什么硬件平台上,所有的数字类型具有相同的长度,不需要程序员去了解这些基础的硬件架构内容。此外,Java程序不会因为段错误而崩溃。虚拟机对内存的自动化管理,避免了C指针误用而引起的内存泄漏崩溃的问题④,而且能够保证使用的变量始终都有正确的类型。尽管具有以上所说的多项优势,但对于早期的Java虚拟器来说,性能仍然是一个长久困扰人们的问题。随着时间的推移,解释器越来越快,而且用来取代解释器的即时编译器⑤能够生成更快的代码。这些新的变化极具吸引力,其他的一些新语言也开始采用虚拟机。目前,虚拟机已经被业界广泛接受,并大量使用。在一定程度上,本书谈论了虚拟机多方面的内容,虽有大量的篇幅用来讲述类文件的格式,但类文件格式正是虚拟机⑥的通用语言。 如果想全面掌握Java语言结构对于虚拟机的意义,那么必须清楚地理解类文件的格式。在虚拟机的世界里,Java语言及其格式是非常简单的。其他编程语言,如C,也有自己对应的ABI(抽象二进制接口)模型,但Java的类文件非常有特色,体现在两个方面。首先,它天生就是面向对象的。其次,它使用动态编译,这就意味着,它所包含的信息远远超过了简单的C对象文件。因此,学习虚拟机获得的知识几乎不能用于那些虽然优秀但已经很古老的非面向对象语言。但对于那些与Java一样使用虚拟机的新程序语言,这些知识就会非常有用。 Java是第一个能够将实际代码和API文档紧密结合在一起的编程语言。通过JavaDoc可以将代码中的注释变成公开的文档,Java提倡开发人员使用这种代码即文档的方式,这样可以保证文档随时都是最新的。尽管其他的编程语言也允许开发人员在代码中加入注释,但只有在Java语言中,才支持通过JavaDoc将相应的注释转成可供程序员使用的文档,从而保持文档和代码的高度一致。另一方面,这也不再是Java特有的功能了。自从这种从代码生成文档的功能被证明了其实用性以后,几乎每一种在Java语言之后创建的新编程语言都支持类似于JavaDoc的文档生成功能。而且在Java语言出现之前就有的语言也提供了额外的工具用来通过代码生成文档。因此,本书虽然只分析了JavaDoc在帮助用户理解API方面的有效性,以及文档格式的利弊,但是,给出的结论几乎可以适用于任何编程语言。 Java 5中开始支持泛型,为Java语言带来多方面的改变。虽然本书并不想成为一本全面讲述Java语言构造的图书,但泛型这样的一个重要特性是不可忽视的。泛型是API设计中的一个重要内容。其新颖之处体现在哪里呢?要知道传统的面向对象语言通过继承来鼓励重用,而其实组合也是一种常见的代码重用形式。只不过大家往往都把注意力集中在继承,而忽略了组合。造成这一问题的根本原因是:继承是面向对象语言内置的特性,而组合则只能由程序员来手工编码,并非常容易出现类型错误。同时,现代已经有大量的语言将组合作为首要的重用方式,其次才是继承,尤其是在Hashell这种函数语言中。有些人认为这两种方式(即继承和组合)各有所长,不可偏颇,所以他们花了大量时间尝试将面向对象语言与多态类型函数语言结合起来。 将继承和组合进行有效结合,这正是Java5⑦中引入泛型的原因。一些人认为泛型过于复杂,对其大肆批评,但我自己在1997年的研究经验表明,几乎无法找到比泛型更加合适的方式了。在这点上,我欣赏Java语言的设计团队,他们在继承和组合这两者之间尽量地保持相对均衡。这也是本书讲述泛型的原因所在。这样做使得本书的部分内容更加贴近于如Haskell这种函数式语言。 本书之所以适合于其他语言,恰恰是因为使用了Java语言。它不是去发明一种特定的新编程语言来处理API问题。整本书都使用我们熟悉的Java语言。书中所有的原则和建议都使用Java固有的编码风格,没有引入任何新的关键字,也不会对前置和后置条件或者对常量的检查进行一些特殊的支持。对于开发一个通用类库的软件工程项目来说,一旦确定了一种开发语言和实现目标,都会设定一个相应的编码风格,约束开发人员使用合适而且统一的编码风格。要知道,学习新API所需要的工作量,与新学习一门编程语言相比,可谓小巫见大巫。 由于具体项目要使用的程序语言是确定的,那么API的设计原则也必然使用该语言来描述。我们相信,如果能使用C语言来编写一个好的API,那么也同样可以使用Java语言来写一个好的API。所以本书中只使用Java语言就足够了。总之,书中提供了可以应用到任何编程语言的通用内容。书中还有一部分内容会更多地讲述面向对象的概念,在需要进行深入讲述时,会使用Java语言给出合适的例子。 ① Haskell是一种纯函数式编程语言,它的命名源自美国数学家Haskell Brooks Curry,他在数学逻辑方面的工作使得函数式编程语言有了广泛的基础。Haskell语言是1990年在编程语言Miranda的基础上标准化的,并且以λ演算为基础发展而来。这也是为什么Haskell语言以希腊字母λ(Lambda)作为自己的标志。——译者注 ② 不同的程序语言中,对于虚方法的定义有所不同,最通用的定义是:能够在运用时才确定的方法就可以称为虚方法,如Java中的非final非static方法,又如C++中的virtual都算是,甚至C语言中的函数指针也可以算作虚方法。 ——译者注 ③ 原文中用的是Link,翻译为连接。——译者注 ④ 在C中,不正确使用指针可能会内存泄露或者是因为缓冲区溢出而导致程序崩溃。——译者注 ⑤ JIT(just-in-time,即时编译)也被称为动态翻译(dynamic translation),是一种通过在运行时将字节码翻译为机器码,从而改善字节码编译语言性能的技术。——译者注 ⑥ 如无特殊说明,书中所指的虚拟机都暗指Java虚拟机。——译者注 ⑦ 作者在原著中同时使用了Java1.5和Java5,以及JDK1.5和JDK5,这两者是相同的,只不过前者是习惯性地沿用了Java一向的命名规则,而后者则是Sun对外的版本,翻译时,都使用Java5和JDK5这两种说法。——译者注

展开全文

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读

《软件框架设计的艺术》其他试读目录

• ***
• API设计的特殊所在
• 读者对象
• 这本书只适用于Java [当前]
• 学习编写API
• 这是一本备忘录吗
• ***
• 1.1 理性主义,经验主义以及无绪①
• 1.2 软件的演变过程
• 1.3 大型软件
• 1.4 漂亮,真理①和优雅
• 1.5 更好的无绪
• ***
• 2.1 分布式开发
• 2.2 模块化应用程序
• 2.3 交流互通才是一切
• 2.4 经验主义编程方式
• 2.5 开发第一个版本通常比较容易