|
精华帖 (0) :: 良好帖 (3) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-09-24
tlde_ti 写道 一直有个疑问.这里问一下
配置文件比配置集中在配置java类有啥优势？ 在java配置类里可以有类型检查，逻辑检查，并且程序员理解维护容易.没有处理配置文件的code. 在配置文件中 修改配置不需要重新编译/修改的代码 添加新配置 也不需要改代码的。 而且配置文件中是通过key=value组成 key其实就是程序员的API。 |
| 返回顶楼 | |
|
发表时间：2012-09-24
最后修改：2012-09-24
jinnianshilongnian 写道 tlde_ti 写道 一直有个疑问.这里问一下
配置文件比配置集中在配置java类有啥优势？ 在java配置类里可以有类型检查，逻辑检查，并且程序员理解维护容易.没有处理配置文件的code. 在配置文件中 修改配置不需要重新编译/修改的代码 添加新配置 也不需要改代码的。 而且配置文件中是通过key=value组成 key其实就是程序员的API。 不用编译 就不可能有类型检查和编译器优化，只有运行时才能知道类型错误。这里看应用场景可以看做优点也可以看做缺点。这里也是我认为的配置文件的最大优势，如果有运行时修改文件的必要的话，很方便. ---------------------------------------------- 在配置文件中 修改配置不需要重新编译/修改的代码 如果是key,value的修改，java类里也可以添加配置只添加一个key,value组到Map中，修改字节数差不多，这里看不出什么区别. -------------------------------------- 添加新配置 也不需要改代码的。 也算是api.不过是隐藏在magic的配置文件之后，不出问题感觉很方便，出了问题排查错误就比较麻烦. ----------------------------------- key其实就是程序员的API ps;谢谢回答，使我对自己对配置文件的看法变得明白了些。. |
| 返回顶楼 | |
|
发表时间：2012-09-24
tlde_ti 写道 jinnianshilongnian 写道 tlde_ti 写道 一直有个疑问.这里问一下
配置文件比配置集中在配置java类有啥优势？ 在java配置类里可以有类型检查，逻辑检查，并且程序员理解维护容易.没有处理配置文件的code. 在配置文件中 修改配置不需要重新编译/修改的代码 添加新配置 也不需要改代码的。 而且配置文件中是通过key=value组成 key其实就是程序员的API。 不用编译 就不可能有类型检查，只有运行时才能知道类型错误。这里看应用场景可以看做优点也可以看做缺点。这里也是我认为的配置文件的最大优势，如果有运行时修改文件的必要的话，很方便. ---------------------------------------------- 在配置文件中 修改配置不需要重新编译/修改的代码 如果是key,value的修改，java类里也可以添加配置只添加一个key,value组到Map中，这里看不出区别. -------------------------------------- 添加新配置 也不需要改代码的。 也算是api.不过是隐藏在magic的配置文件之后，不出问题感觉很方便，出了问题排查错误就比较麻烦. ----------------------------------- key其实就是程序员的API ps;谢谢回答，使我对自己对配置文件的看法变得明白了些。. 没有足够完美的 得失需要自己衡量 |
| 返回顶楼 | |
|
发表时间：2012-09-24
有个疑问，如果依赖关系：
A.jar <-- B.jar <-- C.jar A: ConstantA.A_CODE=1 B: ConstantB.B_CODE=ConstantA.A_CODE C: ConstantC.C_CODE=ConstantB.B_CODE A改变了协议ConstantA.A_CODE=999 那是不是C就抓狂了...... |
| 返回顶楼 | |
|
发表时间：2012-09-24
skzr.org 写道 有个疑问，如果依赖关系：
A.jar <-- B.jar <-- C.jar A: ConstantA.A_CODE=1 B: ConstantB.B_CODE=ConstantA.A_CODE C: ConstantC.C_CODE=ConstantB.B_CODE A改变了协议ConstantA.A_CODE=999 那是不是C就抓狂了...... 是的 
|
| 返回顶楼 | |
|
发表时间：2012-09-24
最后修改：2012-09-24
skzr.org 写道 有个疑问，如果依赖关系：
A.jar <-- B.jar <-- C.jar A: ConstantA.A_CODE=1 B: ConstantB.B_CODE=ConstantA.A_CODE C: ConstantC.C_CODE=ConstantB.B_CODE A改变了协议ConstantA.A_CODE=999 那是不是C就抓狂了...... 这种情况下应该是B针对A的新版本jar包编译一个新的B, 然后C针对B 新的jar包编译一次. 毕竟这里B使用了A的新版本，应该使用新的A jar包编译一次才对. 这样情况下增量编译也不行了，要先clean才不会出问题。 |
| 返回顶楼 | |
|
发表时间：2012-09-24
尼马真的恐怖啊。 |
| 返回顶楼 | |
|
发表时间：2012-09-24
skzr.org 写道
尼马真的恐怖啊。 哈哈哈 |
| 返回顶楼 | |
|
发表时间：2012-09-24
tlde_ti 写道 skzr.org 写道 有个疑问，如果依赖关系：
A.jar <-- B.jar <-- C.jar A: ConstantA.A_CODE=1 B: ConstantB.B_CODE=ConstantA.A_CODE C: ConstantC.C_CODE=ConstantB.B_CODE A改变了协议ConstantA.A_CODE=999 那是不是C就抓狂了...... 这种情况下应该是B针对A的新版本jar包编译一个新的B, 然后C针对B 新的jar包编译一次. 毕竟这里B使用了A的新版本，应该使用新的A jar包编译一次才对. 这样情况下增量编译也不行了，要先clean才不会出问题。 话说是这样 但是没有规范制约 什么情况都可能发生 |
| 返回顶楼 | |
|
发表时间：2012-09-24
我觉得你们过滤了，java类文件之间本来就是一个整体，是你们刻意把单独的拿出来，才导致这样的问题，类之间本来就是有逻辑关系的，而不能割裂开来看
|
| 返回顶楼 | |
