接口优于反射机制（53）

核心反射机制（java.lang.reflect）

• 提供了经过程序访问已装载类信息的途径
• 给定一个Class实例，访问Constructor（构造器）、Method（方法）、Filed（域）

Constructor（构造器）、Method（方法）、Filed（域）实例使得你能够经过反射操做其底层对等体

• 经过调用底层类的实例上的方法，能够构造底层类实例、调用底层类的方法、访问底层类的域
  • 例如Method.invoke 容许你调用任何对象的任何方法  
• 反射机制容许一个类调用另外一个类，即便前者被编译的时候，后者还不存在

反射须要付出代价

• 丧失了编译时类型检查的好处，包括异常检查
  • 若是程序企图用反射调用不存在的类或方法，运行时会报错
• 执行反射访问所用到的代码笨拙、冗长
  • 编写起来乏味、阅读起来困难
• 性能损失
  • 反射方法调用比普通方法慢不少，亲测2倍~50倍不等

反射功能只能在设计时被用到

• 普通应用程序一般应该以正常方式访问到对象，而不是以反射

一些复杂应用程序须要以反射方式访问应用程序

• 好比类浏览器、对象监视器、代码分析器、解释型内嵌式系统
• 在RPC（远程调用）时，使用反射机制也很合适，这样不用存根编译器

以下，建立了一个Set<String>

• 传入参数是 java.util.HashSet、java.util.TreeSet
• 稍加修改可编程可编程通用的集合测试器、或通用的集合性能分析工具

上述实例演示反射机制俩缺点：

1. 可能产生运行时错误，若是不用反射就是编译时错误
2. 反射生成实例，代码冗长

System.exit(1)

• 程序中不多点用这个方法，会终止jvm

类对于运行时可能不存在的其余类、方法或者域的属性，使用反射进行管理是合理的，可是不多用

若是要编写一个包，须要依赖其余包的不一样版本，使用反射就很是有用

• 这种方式容许使用最小环境进行编译，而后使用反射访问其余更新版本内容

反射机制是功能很是强大的机制

• 若是编写的程序必须与编译时未知的类一块儿工做，请仅仅使用反射建立新实例
• 使用实例的接口或者超类进行方法或域的访问