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

程序中,变量活动范围有:方法/函数(局部)里的,成员变量(全局变量)

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

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

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

  • 1)利用java语言的特性,从方法变量编程成员变量

  • 2)java语言特性,编程静态变量

  • 3)通过单例,存储在手机内存中

  • 4)放在Application中(严格说,这种方法其实也属于3)中的单例法)

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

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

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

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

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