自定义工具库

王朝other·作者佚名  2008-05-19
窄屏简体版  字體: |||超大  

自定义工具库

掌握前述的知识后,接下来就可以开始创建自己的工具库,以便减少或者完全消除重复的代码。例如,可为System.out.println()创建一个别名,减少重复键入的代码量。它可以是名为tools的一个包(package)的一部分:

//: P.java

// The P.rint & P.rintln shorthand

package com.bruceeckel.tools;

public class P {

public static void rint(Object obj) {

System.out.print(obj);

}

public static void rint(String s) {

System.out.print(s);

}

public static void rint(char[] s) {

System.out.print(s);

}

public static void rint(char c) {

System.out.print(c);

}

public static void rint(int i) {

System.out.print(i);

}

public static void rint(long l) {

System.out.print(l);

}

public static void rint(float f) {

System.out.print(f);

}

public static void rint(double d) {

System.out.print(d);

}

public static void rint(boolean b) {

System.out.print(b);

}

public static void rintln() {

System.out.println();

}

public static void rintln(Object obj) {

System.out.println(obj);

}

public static void rintln(String s) {

System.out.println(s);

}

public static void rintln(char[] s) {

System.out.println(s);

}

public static void rintln(char c) {

System.out.println(c);

}

public static void rintln(int i) {

System.out.println(i);

}

public static void rintln(long l) {

System.out.println(l);

}

public static void rintln(float f) {

System.out.println(f);

}

public static void rintln(double d) {

System.out.println(d);

}

public static void rintln(boolean b) {

System.out.println(b);

}

} ///:~

所有不同的数据类型现在都可以在一个新行输出(P.rintln()),或者不在一个新行输出(P.rint())。

大家可能会猜想这个文件所在的目录必须从某个CLASSPATH位置开始,然后继续com/bruceeckel/tools。编译完毕后,利用一个import语句,即可在自己系统的任何地方使用P.class文件。如下所示:

ToolTest.java

所以从现在开始,无论什么时候只要做出了一个有用的新工具,就可将其加入tools目录(或者自己的个人util或tools目录)。

CLASSPATH的陷阱

P.java文件存在一个非常有趣的陷阱。特别是对于早期的Java实现方案来说,类路径的正确设定通常都是很困难的一项工作。编写这本书的时候,我引入了P.java文件,它最初看起来似乎工作很正常。但在某些情况下,却开始出现中断。在很长的时间里,我都确信这是Java或其他什么在实现时一个错误。但最后,我终于发现在一个地方引入了一个程序(即第17章要说明的CodePackager.java),它使用了一个不同的类P。由于它作为一个工具使用,所以有时候会进入类路径里;另一些时候则不会这样。但只要它进入类路径,那么假若执行的程序需要寻找com.bruceeckel.tools中的类,Java首先发现的就是CodePackager.java中的P。此时,编译器会报告一个特定的方法没有找到。这当然是非常令人头疼的,因为我们在前面的类P里明明看到了这个方法,而且根本没有更多的诊断报告可为我们提供一条线索,让我们知道找到的是一个完全不同的类(那甚至不是public的)。

乍一看来,这似乎是编译器的一个错误,但假若考察import语句,就会发现它只是说:“在这里可能发现了P”。然而,我们假定的是编译器搜索自己类路径的任何地方,所以一旦它发现一个P,就会使用它;若在搜索过程中发现了“错误的”一个,它就会停止搜索。这与我们在前面表述的稍微有些区别,因为存在一些讨厌的类,它们都位于包内。而这里有一个不在包内的P,但仍可在常规的类路径搜索过程中找到。

如果您遇到象这样的情况,请务必保证对于类路径的每个地方,每个名字都仅存在一个类。

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航