Java中对变量范围转换引发的思考

程序中，变量活动范围有：方法/函数（局部）里的，成员变量（全局变量）

当一个变量从局部变量升级到全局变量，该变量可以跨方法使用，因此在一个方法里对该变量赋值，在另一个方法里就能马上感知到并获取变量的值，体现着监听设计思想。

变量升级，并不是都带来了好的方面。一个变量升级后，就要求程序员考虑是否需要对这个变量进行维护。（所谓维护就是该变量是否处在一个循环中）如果需要维护，即变量处在循环中，则要考虑是否需要对该变量进行初始化和善后处理（因为全局变量是和其他变量或方法相互联系的）如果需要，则进一步考虑变量在循环中从0次，到1次，到2次的变化过程，并从这三次变化过程中提取规律。如果获取规律？程序员的经验以及一些更底层的规律。

把一个变量从局部编程全局的途径有如下方法：

1）利用java语言的特性，从方法变量编程成员变量

2）java语言特性，编程静态变量

3）通过单例，存储在手机内存中

4）放在Application中（严格说，这种方法其实也属于3）中的单例法）

5）存储在本地，需要用到的时候，再从本地获取。比如SharedPeference，IO流写入和读取。

以便变量从全局变量降级成局部变量，带来的好处就是降低了变量维护难度。只需要在该方法作用范围内考虑，同时对变量个体而言，作用范围的缩小，自然增加了变量作用的安全性。

由此，还可以推广到逻辑思考切入点事宜。

一个问题，肯定是处在特定的范围或事件中的。澄清前提，划清界限很有必要。解决一个问题，修复一个bug，首先需要把这个bug产生的起始点找到，这个起始点有时候是浮动的，可以往前多些，也可以往后移些。找到bug的起始点后，还要清楚这个bug的结束点。在这起始点和结束点之间的这一段范围里，我们去修改这个bug。为了定位bug，有时候当第一直觉和感知还无法定位bug的时候，就需要对这一段范围进行切割分段。如何切割？切割的依据是什么？这里涉及到责任链，可以选取一个范围大小的责任链作为参考进行分割，其实也即是业务逻辑功能模块来分割。然后定位到某一段时，再次分割。

这种循序渐进的方式，带来了逻辑的严密，bug就不容易被我们漏过。面对问题，只要有严密的思路和逻辑对bug和问题进行分解、拆分，加上有效时间的累积实践和反馈，就一定能找到解决和修复的方法。