团队遵守Command和Query分离的编码习惯能让后来者快速融入开发
这两天在逐步融入新的开发团队和新的项目，在熟悉代码和业务逻辑的同时也做一些小的功能开发。在这个过程中，遇到了一些小插曲引发了我的一点点思考。
比如说下面的例子：
//初始化SomeDataA的方法，以SomeDataB为参数
public SomeDataA initData(SomeDataB someDataB){
//.....
}
我的代码将要调用这个方法来返回一个someDataA实例，传入的是一个someDataB实例。从方法命名和返回值类型的角度来看，应该是根据someDataB的状态来初始化一个SomeDataA的实例给我。这都很正常，可是成语的运行结果和我想象的不同，调试之后我才发现，原来是参数someDataB的状态在调用前后发生了变化。也就是说这个方法在给我返回值的同时修改了传入参数someDataB的内容！然而这一切并没有任何暗示。虽然这个小问题并不太影响开发，语法层面也没有任何对这种操作的限制。不过如果已有代码中大量存在这样的情况的话，对于使用者总会有种“步步惊心”的感觉。总怕某个调用会引起一些意想不到的结果。
后来查了查，有这样一个提法"Command与Query分离”。其基本思想是对象的方法应该清晰明确的分为以下两种：
Query方法:返回结果但不修改系统的当前状态（无副作用）
Modifier方法:修改系统的状态但无返回值。
这样做的好处在于，把修改状态的方法和不修改状态的方法明确区分。在许多情况下可以有把握的调用Query，甚至调换调用顺序，不用担心副作用；只有在调用modifier方法时才需谨慎。
如果开发过程中尽可能的遵守如上的规则，那么对于一个新加入的开发人员来说，可以避免很多问题，当然维护起来也更容易。
