结对编程与OO冲突吗？
记得以前听说过，面向对象思想提倡信息隐藏。在一个项目中，对其他程序员编写的代码，除了API之外，不应该有太多的了解，不应该猜测、分析他代码中的逻辑。
这几天看《敏捷软件开发》，书中提到：
“结对的关系每天至少要改变一次,以便于每个程序员在一天中可以在两个不同的结对中工作.在一次迭代期间,每个团队成员应该和所有其他的团队成员在一起工作过,并且他们应该参与了本次迭代中所涉及的每项工作.”
“这将极大地促进知识在团队中的传播.仍然会需要一些专业知识,并且那些需要一定专业知识的任务通常需要合适的专家去完成,但是那些专家几乎会和团队中的所有其他人结过对.这将加快专业知识在团队中的传播.这样,在紧要关头,其他团队成员就能够代替所需要的专家.”
即作者鼓励小组成员了解其他成员的代码。
这么看来，结对编程时的代码共享，与面向对象提倡的信息隐藏，似乎是冲突的。难道真是如此吗？或者有其他的什么解释？
[解决办法]
1.不可能分工永远清楚，人员调动，后期维护，系统调试都会要求你去修改别人写的代码
2.两人合作，既可以互相帮助，也可以讨论和共同提高
3.可以大量减少低级的BUG，比如用错变量名之类的。
[解决办法]
还是我上面说的，所谓隐藏是不要把不相干的拿出来干扰人，而不是把需要的信息藏起来不给别人。这种更高层次的抽象是在代码级别的服务，而不是和人的理解相冲突。打个比方来说，你开车的时候，转动方向盘会带动一系列传动装置最后控制轮子做转向。不论机制多么复杂，你都只需要转方向盘就行了；同样，不论你多么了解内部机制，也不会自己伸手到汽车内部去扳动齿轮。
抽象是在理解基础上的思考方式，而不是无知的结果。
还有一个重要原因，因为在项目小组中并没有真正意义上的这种职责划分。一个很简单的证明，司机可以给你解释说车子坏了所以不能继续开。你并不能给客户说因为是另一个人程序有问题所以你没责任。这种抽象层次的划分和设计本身也是开发小组自己做出的，当然是大家更多更全面了解问题有助于更好的设计。相反，在初期根据某些原因做了一个初步划分，然后就每人只看到自己的一部分，再下来因为没有人有整体的了解，就更加固守当初的划分。这不叫抽象，仅仅是分割而已。就像你看到照片时候看到的是：人，房子，天空和树木，而一个图像程序是把它分成四个等分的方块。你希望项目组中的人看到的是前一种还是后一种图景呢？
