我们经常会遇到当前功能不满足现状的时候，如果是原来业务代码的话并且量少，我们就会直接改动源码逻辑来解决这个问题;如果是业务代码且量大，这种一般为共性问题，一般会统一处理解决，例如在数据吐出的时候，遍历增强数据内容，已满足需求，或者是原来代码的抽象，使用代理模式，装饰模式等等，让代码更好看，逻辑看起来更明确。
第三方库
上面说的情况，代码都是自己的情况，因为是自己的代码，所以控制这些都是相对比较open的，原来设计的一些情况，不满足就改，但是当引用的是第三方库的代码的时候，我们就会遇到很多的麻烦。
正常流程，我们会做功能增强，一般表现为代理模式。典型的就是数据库连接池。也有沿用原来的方式的，例如扩展io。原来就是装饰者模式，现在扩展，继续使用装饰者模式，还有filter，本身就是责任链模式，我们新加的话，直接把代码写好后加入配置即可。
上面说的这几种情况都是相对比较友好的情况。就是第三方库本身就比较喜欢开放，而且本身还有一些支持。
不想被扩展的编码
final
使用final关键字修饰。如果你想用一个增强的类动态替换掉原来的对象，结果对方的成员变量的描述是final的，一旦赋值不能替换。这个只能在赋值的时候必须完成增强，带来很多麻烦。
包访问权限
有些情况，我们本身比较适合继承增强，但是父类都是包访问权限，我们自己的代码一般不会和第三方的同包名。所以这种情况也是访问不到的
collections集合
emptyList(),emptyMap() ,emptySet()。通过collections创建的这几种集合都是空的，且不可变，不支持什么增删改操作。想加入一些额外的数据的时候，发现根本加布进去，必须选择替换集合的方式。
arrays
asList也是一个不可修改的集合。问题和解决方案同上。
后门
上面的问题这么多，如果遇到优先选择一些正常的手段，在正常逻辑上找出合适的方法来增强。
如果没有就只能选择一些java的特定方法了。
反射
反射可以做值的修改，没有什么限制，就是后期维护代码会比较麻烦，而且使用了字符串操作，在类找调用的时候是找不到的。
字节码修改
字节码是可以redefine或者transform的。所以在类加载的时候替换掉字节码文件中让你头疼的部分的就可以。如果不知道怎么做，查一下jvmti以及asm,javassist即可。
总结