当参数个数多于三个的时候，通常会将这些参数封装到一个类中，进而形成参数类。参数类通常是类间或方法间进行通信的纽带，起到承上启下的作用。
基本上一个稍微有些规模的项目都会由多个模块组成，而这些模块的内部又都会分为多个层级，如controller、service、dao等。如果一个参数类被像针一样，一传到底，跨越多个模块、多个层级，结果会导致坑越来越深。下面来一一细说这些深坑。
改一处而动全身
举个例子，一个项目由A、B、C三个模块组成，A模块用于接收http请求，相当于网关；B模块提供具体的业务处理服务；C模块提供基础的CRUD操作。A调用B，B调用C，完成一次请求到响应的流程。此时，如果设计了一个参数类用于接收http请求的参数，在调用B模块中服务方法的时候，直接将该参数类传到B中，又不巧B调用C中的服务方法，直接将该参数又传递到了C中。看到这里可能有人会说不会吧！笔者也是这么认为的，然而这是真事。如果此时说需求变了，要把一个参数名称改掉，这样就会导致改一处而改全部，所有用到的模块都需要改，进而相应的模块都需要重新进行回归测试，费神费力。
如果针对每个模块定义一个自身范围内使用的参数类就不会有这么多的麻烦，A模块你改你的，B、C模块可以根据情况而定，可不改！
这种设计就是低耦合的反例，一传到底串联了太多，导致耦合性太高！
结构臃肿
还是使用上面的例子。参数类在A中接收http请求参数的时候，需要三个属性，然而在调用B的时候需要五个属性，B在调用C的时候需要六个属性，这就会导致参数类的属性不断堆积，最终导致参数类结构臃肿，随着时间的推移，可能连原作者都不知道需要传哪些参数，哪些参数是不需要的。这种把不相关的属性都堆积到一个类中的做法很常见，笔者只能说偷懒到极致了。
职责不单一
上面说的是结构臃肿，实际上是设计上的错误。谈到面向接口编程，设计接口的时候要做到职责单一，这个接口在笔者看来不单单是interface，而是所有具备通信的地方，比如接口、类、方法。将多种用途的参数都堆积到一个类中，明显违反了这个设计原则。
究其原因
造成这种一传传到底做法的原因有两种：
一是刚入行编码人员缺乏经验编写导致；
二是多年经验的老手，一心为了实现代码的复用与简单原则，编写少的代码实现强大的“通用”。
说到通用，大可不必这么做！如果有两个类的大部分属性相同，可以使用Dozer做转换，使用上很简便，在多数情况下不用做过多配置即可实现类之间的转换，具体可以翻看很早之前的一篇详细介绍内容。
小结
总结就是不要设计或使用一个参数类一传传到底。做到高内聚低耦合，职责单一，大道至简！
