自定义工具库

中间人

　　自定义工具库 　　掌握前述的知识后，接下来就可以开始创建自己的工具库，以便减少或者完全消除重复的代码。例如，可为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，但仍可在常规的类路径搜索过程中找到。 　　如果您遇到象这样的情况，请务必保证对于类路径的每个地方，每个名字都仅存在一个类。