当前位置: 代码迷 >> J2EE >> 看不懂代码了,求
  详细解决方案

看不懂代码了,求

热度:232   发布时间:2016-04-22 02:35:26.0
看不懂代码了,求高手指点
新进了一家公司,主要是修改以前的东西,现在看着前人写下的代码,感觉有点看不懂了,请高手指点。
  一,在他的一个类了,定义了N多公共静态变量(public static final),既然是公共静态的变量,干嘛不抽出来专门定义,免得到时候修改得时候需要多处地方修改。这样不是不便于管理吗?
  二,他接着又定义了N多全局变量,这个我以前没有见多少(我是个小菜),在他得逻辑里面,方法多没有返回值,而是去修改那个定义的全局变量,然后另写一个方法去获取那个全局变量。这个我没有见过。那位可以给我指点指点。用全局变量要是别的方法改变了变量的值,你再去取得,那不获取的不是你要的值了吗。这个和在方法里定义一个局部变量然后返回又什么区别吗,又什么好得地方吗?

------解决方案--------------------
第一问题,我支持你的想法并肯定,抽出来专门定义,更好》

第二问题,真不知道怎么说,好处坏处也说不上来。主要看系统业务更适合哪个吧。

等待高人帮你解释
------解决方案--------------------
一, 公共静态变量不需要多处修改。如果你指的是把多个类的公共静态变量抽到一个类里去定义,这样并不好,因为类变量的含义往往依托于类本身才有意义,是组成对象(数据+操作)的一个重要部分。

二, 这种写法不好。调试困难,Bug难追踪,可读性差,更重要的是,多线程下几乎是致命的。
------解决方案--------------------
探讨

一, 公共静态变量不需要多处修改。如果你指的是把多个类的公共静态变量抽到一个类里去定义,这样并不好,因为类变量的含义往往依托于类本身才有意义,是组成对象(数据+操作)的一个重要部分。

二, 这种写法不好。调试困难,Bug难追踪,可读性差,更重要的是,多线程下几乎是致命的。

------解决方案--------------------
一:支持lz的想法,在java doc里面大部分都是这样写的。抽出来定义,可以统一管理。虽然类变量的含义往往依托于类本身才有意义,但是静态变量就令当别论了。
二:这种写法很不好,很容易出现冲突。特别是当多个用户同时访问这个文件,那么全局变量的值可能会冲突。但除非特殊的需求,否则就不要用全局变量了。
------解决方案--------------------
这种写法不好是显而易见的 可读性低

你就debug 硬着头皮看吧
------解决方案--------------------
第一个,这种public static final常量的方式是常有的,就比如Calendar.YEAR, Calendar.MONTH等等,这些主要是为了定义一些规范的参数,也就是调用结果的时候可能会用到的参数由该类来保证和管理,就像Calendar.YEAR,你用System.out.println(Calendar.YEAR)能看到它是多少,也就是说你使用Calendar.YEAR和使用打印出来看到的整数效果是一样的,但是你用一个无意义的整数,程序看上去不好理解,也不方便管理(这里要注意,定义好了一个这样的常量,你就不要轻易改变它的名字,你可以改变它的值,这样程序是不需要修改的,你所说的需要多处修改,不方便管理,可能是你把常量的名字改变了,否则不会不方便管理的)

第二个,这种方式就像你说的,从线程安全角度来考虑是不可取的,不过也不清楚你的具体业务,从某种情况来说,它也有可取的地方,比如就像你说的,它可能就是会被多个线程(调用方法)给修改,而你正好需要的就是这种被修改后的状态的感知和判断,如果用方法返回,就不能达到这种状态的统一管理控制。所以这种情况要具体情况具体分析。估计它这些变量还带着volatile关键字了吧。




------解决方案--------------------
静态变量不是在类加载时已经存在了吗?说明他是不需要多处修改地吧
------解决方案--------------------
第一:你要清楚这些静态常量是否是只在这个function中使用还是普遍使用的
第二:如果普遍使用,那么使用封装概念, 我们就可以单独定义一个constant类
第三:如果只在这个function当中使用过,那就没必要单独抽出来了

so,不是什么东西抽出来单独封装就好的,要根据实际业务逻辑平衡好
------解决方案--------------------
我也再改遗留的系统,基础架构是很不错的,但是越来越乱,越来越复杂,外包的人是一波波的换。唉!
------解决方案--------------------
1我同意LZ的,2我也觉得全局变量这玩意不是定义的越多越好,说不定名字重复造成的错误还不容易找
------解决方案--------------------
lz想法是不错的,但这种情况见怪不怪 慢慢就会适应的 如果有时间的话可以重构一下 也许是他们以前做这项目时很敢先实现功能再说 又或许有些项目侧重点是稳定运行(就不用改了).
------解决方案--------------------
现有用户(User)表,字段uid 角色表(role),字段rid 中间表(user_role),字段:uid,rid
相信大家一看就知道怎么回事了,现在我想在中间表中删除一条记录,要求控制台输出:
delete user_role where uid=? and rid =?
用户表中的配置
<set name="roles" table="USER_ROLE" cascade="save-update" lazy="false" inverse="false">
<key column="USER_ID"></key>
<many-to-many column="ROLE_ID" class="Role"/>
</set>
角色表中的配置
<set name="users" table="USER_ROLE" cascade="save-update" lazy="false" inverse="true">
<key column="ROLE_ID"></key>
<many-to-many column="USER_ID" class="Users"/>
</set>
测试时写的代码:
Users user = userservice.searchUsersByUid(7);
  相关解决方案