最近接手公司服务端接口的相关编写工作，遇到了一些问题，提出了一些想法，讨论了一些问题，与项目经理在方案选择上有了一番争吵（当然，这种争吵是家常便饭的事儿）。特此有了一些心得体会。
方法入参的设计
我们在设计程序的时候，如果使用常规的分层模型，既Controller、Service、Dao，来对项目进行分层，一定会遇到一个问题，就是不同层及之间，数据传递，即每个方法的“入参”应该怎么设计。
我曾待在一家从事银行系统开发的公司，项目有一个很大的特点，它并非使用C、S、D来进行分层开发，当然这不是重点，重点是它虽然使用Java，但是大部分不以面向对象的形式来编写程序，项目中随处可见的是static的静态方法，几乎什么功能都可以用静态方法来完成，我的理解它已然是一个用java以面向过程的思想开发的项目。这个项目在方法之间传递数据时，不适用对象封装，而是采取多个入参的形式，所以很常见的就是要一个方法，有N多个入参，5个是常见、10个都不特殊。这种方式来编写方法，有一定的缺点：
在阅读代码的时候，经常会不明白参数的意义，而需要仔细的去看javaDoc上的注释，影响效率；
调用一些工具时，因为不是以面向对象的方式去设计程序，所以所有变量的作用域自然只在方法体内，于是对于一些需要设置参数的工具，简单的例如：分页工具，就需要通过一大堆的入参，经常会搞不懂入参的意义，每次调用起来需要重新设置一大堆的参数值；或者使用一个Map来装载这些参数，这样带来的问题就是你甚至不知道有什么参数需要设置，经常会出现错误。
