平时写一些代码的时候不像写一些框架涉及到具体的业务比较少，或者也不能说比较少，只是涉及到的业务感比较轻,现在一般的公司的代码都是具有很强的业务感觉。
而且一般写这些的时候还用框架，比如说比较流行的SSI或者是SSH。然后分模块开发。
当我们用这些框架开发的时候往往是一个Service提供接口给本模块或者其它模块使用。这个时候一个Service往往会包含很多各式各样的接口。这个时候往往会发生以下问题:
因为Service是对外提供方法服务的，所以处理异常就会放在Service，这个时候没有接口都需要附带2个信息：
这样子可能会出现以下几个问题：
写了很长一段时间业务代码以后。给我的感觉是,程序员并不是在写代码，而是在搞业务,基本上不会涉及到抽象或者抽象成分很小很小。
怎么才能写出比较理想的业务代码,还是业务代码只能这么过程式的去写？
Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
3
995
收藏
首先任何功能的执行，说到底还是一个过程，先做什么再做什么，第一步第二步，这是肯定的，理清这个过程是实现的第一步。然后，面向对象的设计要求我们把过程中的每一步委托给合适的类来做，读文件让谁来做，排序让谁来做，解析xml让谁来做。这样职责委派的结果，就是程序内出现了模块分层，被依赖得多的模块，通常被视为底层。
当对象在模块之间进行传递时，是否每个模块都要判断其合法性？commons-lang的StringUtils是个例子，它用来处理字符串，而它的所有方法都能很好的处理null参数值，所以它发出了一个很明确的信号：不要在调用我的方法前检查参数是否为null，只管传给我好了！至于你自己写的方法，对参数有什么要求，最好在文档里说明，这样调用者也省心。
日志记录，每个模块都是在自己的角度上去理解要不要记，所以如果你觉得某个地方重复了的话，通过调整配置屏蔽掉多余的就好。
文中你说的两个问题应该是c++才容易遇到的,java一般不用状态码,而是使用异常