锁定老帖子 主题:编程中一个很常见的问题,有帮助的
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (17)
|
|
---|---|
作者 | 正文 |
发表时间:2008-12-13
第一种层次感强,各层依赖调用,不过方法多了深度太大,中间环节出现问题不好处理第二种统一调度,灵活性会比较大,相当与用一个大脑,调度了每个肢体。便于组合和复用。对于异常也能从全局的角度去分析处理。我比较会倾向第二种。
|
|
返回顶楼 | |
发表时间:2008-12-13
我觉得,这是一个"方法调用深度"的问题
有时候从整个项目来看 代码结构上出现第一种情况是难以避免的 比如,一般我们这么干的时候:Action-->Service-->DAO 那么就已经三层的调用深度了,然后在某个类的某个方面里面又可能再次地深度调用 那么方法调用的深度就非常深了 用过Spring的人都知道,一旦出现异常的时候,打印出来的异常堆栈是很长的 有时候会到几十个,那么它可能就出现了非常深的方法调用 不是吗? 所以我觉得,只要在设计和大框架上没有大的问题 不必刻意去避免深度调用 |
|
返回顶楼 | |
发表时间:2008-12-13
抛出异常的爱 写道 如果让我来选.
我会选第二种 由于没有逻辑可言的情况下 第二种的代码信息含量更接近5这个数.... 更易让人记忆与查寻..... 如果第一种更合乎业务逻辑 那么就选第一种. 那样子,业务逻辑与代码逻辑总共只需要记忆一次 比另一种少记忆一次. OO的主要目的就是少记忆 ,快速查找 OO的选择就是把自己当作一个有限大小 的一个cacahe要尽量提高命中率 第二种写法是正常的写法!!! |
|
返回顶楼 | |
发表时间:2008-12-13
具体情况具体分析
良好的代码应该是尽量降低耦合 第一种调用,A->B->C->D->E->.... 明显是代码有强烈的耦合嘛,每个调用都要保持状态等待子调用结束来继续,这样就需要保持一个很深的call stack 第二种调用,BCDE...之间没有耦合,每个function调用结束就return了,call stack就一个A的被一直保持着,这样会比较好吧 假设BCDEFGH...是同样的一个function的话,明显就是一个 recursive process 和 iterative process的区别 尾递归的优化结果就跟第二种类似嘛 除非是没办法,不然代码应该尽量往第二种靠 |
|
返回顶楼 | |
发表时间:2008-12-13
最后修改:2008-12-13
问题很难回答,
我05年设计一个架构之前也被这个问题为难过. 最后也没什么好的解决方案,采用了第一种. 其中参数和Exception是这样定义的.参数统一用一个Param类这个类继承于HashMap,用法类似于HttpRequest.getParameter,在方法注释中写明需要什么参数 Exception统一继承于一个根Exception,其它Exception用这个类的transException转换为当前Exception. 用了一段时间发现这个方案也不怎么好...呵呵. 具体问题具体分析吧. |
|
返回顶楼 | |
发表时间:2008-12-14
看了6页,有点累,总结如下:
1.多数人应该都听过重构这个词儿,了解他的概念和基本手段,真正做过的应该也不占少数。 2.针对这个贴的问题,我认为具体问题具体分析。如果test1和test2干的是两件事,那应该用第一种方法,如果test2是为test1工作的,那应该用第二中方法。 |
|
返回顶楼 | |
发表时间:2008-12-14
puroc 写道 看了6页,有点累,总结如下:
1.多数人应该都听过重构这个词儿,了解他的概念和基本手段,真正做过的应该也不占少数。 2.针对这个贴的问题,我认为具体问题具体分析。如果test1和test2干的是两件事,那应该用第一种方法,如果test2是为test1工作的,那应该用第二中方法。 同意。。。 |
|
返回顶楼 | |
发表时间:2008-12-14
最后修改:2008-12-14
恩,希望每个程序员有时间的时候都能够去重构下自己的代码,我个人觉得这一点很重要,它可以快速的提高你的编程能力。如果把好的结构提高一个层次到架构上,那么将对设计有帮助。 个人肤浅的见解,不过千万不要小看重构。
|
|
返回顶楼 | |
发表时间:2008-12-15
初看第二种好
|
|
返回顶楼 | |
发表时间:2008-12-15
fjlyxx 写道 难道你们的系统都没有进行过重构吗? 好的系统是重构出来的,好好的看看重构的原则,如果你没有这么做过,你怎么会发现模式的重要。如果你的接口都是随便定义的那么你怎么能体会这两种方式的区别呢?
public Object findUser(final Map parameters) { return this.getSqlMapClientTemplate().queryForObject("findUser", parameters); // | | | // 返回结果 组装SQL并执行数据库操作 根据用户输入 这完全是一个不合格程序员写的代码。 去看看自己作的系统中有多少这样的情况,不是我自大,我只是想提醒这么一种常见的错误,让后辈人少走点弯路。 这是一个工具式方法,我觉得很好啊,spring的uncheck exception的初衷就是为了避免不必要的exception check. 具体业务处理时去检查异常,service里面dou不需要 action (){ try{ service.do..; }catch(..){ //todo } } |
|
返回顶楼 | |