再谈反射

          最近在一次技术分享会上继续分享了反射机制，每次的分享都让自己对它有个更深入的认识。下面是由TKY某项目中项目经历搭建的框架，自己深入的整理了下，并对以此对反射有了一层又一层的深刻认识，同时借鉴了他人的博客以及视频讲解，产生了共鸣。

       反射在运行时动态的实例化对象，动态的调用对象。 即：

       在运行时判断任意一个对象所属的类；

       在运行时构造任意一个类的对象；

       在运行时判断任意一个类所具有的成员变量和方法；

       在运行时调用任意及一个对象的方法。

       下面将从整体局部的思路整理的结构图。

                       

       依据依赖倒转的原则，同时将业务类进行抽象，增加了系统的灵活性和扩展性；

                     

     通过反射机制获取程序自身类方法属性，实现动态运行时实例化对象。

     以此为题，再一次引发自己对反射的思考。下面引子一篇博客

    （一） 反射适应什么样的场景，什么情况下没有发射是无法实现的？

     1）.Java的反射机制在做基础框架的时候非常有用，有一句话这么说来着：反射机制是很多Java框架的基石。而一般应用层面很少用，不过这种东西，现在很多开源框架基本都已经给你封装好了，自己基本用不着写。典型的除了Hibernate之外，还有Spring也用到很多反射机制。经典的就是在xml文件或者properties里面写好了配置，然后在Java类里面解析xml或properties里面的内容，得到一个字符串，然后用反射机制，根据这个字符串获得某个类的Class实例，这样就可以动态配置一些东西，不用每一次都要在代码里面去new或者做其他的事情，以后要改的话直接改配置文件，代码维护起来就很方便了，同时有时候要适应某些需求，Java类里面不一定能直接调用另外的方法，这时候也可以通过反射机制来实现。
总的来说，自己写的很少，具体什么时候要用那要看需求，反射机制无非就是根据一个String来得到你要的实体对象，然后调用它原来的东西。但是如果是要自己写框架的话，那就会用得比较多了。

      2）当你做一个软件可以安装插件的功能，你连插件的类型名称都不知道，你怎么实例化这个对象呢？因为程序是支持插件的（第三方的），在开发的时候并不知道 。所以无法在代码中 New出来 ，但反射可以，通过反射，动态加载程序集，然后读出类，检查标记之后再实例化对象，就可以获得正确的类实例。

    3）在编码阶段不知道那个类名,要在运行期从配置文件读取类名, 这时候就没有办法硬编码new ClassName(),而必须用到反射才能创建这个对象.反射的目的就是为了扩展未知的应用。比如你写了一个程序，这个程序定义了一些接口，只要实现了这些接口的dll都可以作为插件来插入到这个程序中。那么怎么实现呢？就可以通过反射来实现。就是把dll加载进内存，然后通过反射的方式来调用dll中的方法。很多工厂模式就是使用的反射。

     

      （二）程序员在自己的业务开发中应该尽量的远离反射

反射：在流行的库如Spring和Hibernate中，反射自然有其用武之地。不过内省业务代码在很多时候都不是一件好事，原因有很多，一般情况下我总是建议大家不要使用反射。

首先是代码可读性与工具支持。打开熟悉的IDE，寻找你的Java代码的内部依赖，很容易吧。现在，使用反射来替换掉你的代码然后再试一下，结果如何呢？如果通过反射来修改已经封装好的对象状态，那么结果将会变得更加不可控。请看看如下示例代码：

                                        

     

        如果这样做就无法得到编译期的安全保证。就像上面这个示例一样，你会发现如果getDeclaredField()方法调用的参数输错了，那么只有在运行期才能发现。要知道的是，寻找运行期Bug的难度要远远超过编译期的Bug。

        最后还要谈谈代价问题。JIT对反射的优化程度是不同的，有些优化时间会更长一些，而有些甚至是无法应用优化。因此，有时反射的性能损失可以达到几个数量级的差别。不过在典型的业务应用中，你可能不会注意到这个代价。

总结一下，我觉得在业务代码中唯一合理(直接)使用反射的场景是通过AOP。除此之外，你最好远离反射这一特性。 

       反复的接触一个事情才能对其有一个更为深刻的认识。庆幸有这次分享的机会。反复的学习和思考带给自己一个更为广阔的空间，站在更高的角度思考问题。