给定一个类的Class实例，你可以获得这个类的Constructor的实例(类型为Constructor)，Method的实例（类型为Method），Field的实例（类型为Field）
，分别代表了Class实例所代表类的Constructor（构造器），Method（方法）和Field（域）。这些对象提供了“通过程序来访问类的成员名称，域类型，
方法签名等信息”的能力。
而且，Constructor，Method和Field实例使你能够通过反射机制操作它们的底层对等体（就是这个类的构造器，方法，域），通过调用Constructor，Method
和Field实例上的方法，你可以构造底层类的实例，调用底层类的方法，并访问底层类中的域。反射机制允许一个类使用另一个类，即使当前者被编译的时候后者
还根本不存在。然而这种能力需要付出代价：
1.丧失了编译时类型检查的好处，包括异常检查。如果程序企图通过反射机制调用不存在的或者不可访问的方法，编译时没有错误，但是运行时它将会失败。
2.执行反射访问所需要的代码非常笨拙和冗长。阅读困难，编写乏味。
3.性能损失。
反射功能只是在设计时被用到。通常，普通应用程序在运行时不应该以反射的方式访问对象。
如果只是以非常有限的形式来使用反射机制，虽然需要付出少许代价，但是可以获得许多好处。
对于有些程序，它们必须用到在编译时无法获取的类，但是在编译时存在适当的接口或者超类，通过它们可以引用到这个类。如果是这种情况，就可以以反射方式
创建实例，然后通过它们的接口或者超类，以正常的方式访问这些实例。
具体的示例代码见书的202页。
简而言之，反射机制是一种功能强大的机制，对于特定的复杂系统编程任务，它是非常必要的，但是它也有一些缺点。如果你编写的程序必须要和你编写的程序编译时未知的类一起工作，如有可能，就应该使用反射机制来实例化对象，而访问对象时则使用编译时已知的某个接口或者超类。