kent

Summary ：有个函数返回一个集合。 让这个函数返回该集合的一个只读副本，并在这个类中提供添加 / 移除集合元素的函数 Motivation: 我们常常会在一个类中使用集合（ collection ，可能是 array 、 list 、 set 或 vector ）来保存一组实例。这样的类通常也会提供针对该集合的取值 / 设值函数。 但是，集合的处理方式应该和其他种类的数据略有不同。取值函数不该返回集合自身，因为这会让用户得以修改集合内容而集合拥有者却一无所悉。这也会对用户暴露过多对象内部数据结构的信息。如果一个取值函数确实需要返回多个值，它应该避免用户直接操作对象内所保存的集合，并隐藏对象内与用户无关的数据结构。至于如何做到这一点，视你使用的 java 版本不同而有所不同。另外，不应该为这整个结婚提供一个设置函数，但应该提供用以为集合添加 / 移除元素的函数。这样，集合拥有者（对象）就可以控制集合元素的添加和移除。 如果你做到以上几点，集合就被很好的封装起来了，这便可以降低集合拥有者和用户之间的耦合度。 Mechanics ： 1. 加入为集合添加 / 移除元素的函数 2. 将保存集合的字段初始化为一个空集合。 3. 编译。 4. 找出集合设值函数的所有调用者。你可以修改那个设值函数，让它使用上述新建立的“添加 / 移除元素”函数；也可以直接修改调用端

这篇文章主要来源是StackOverflow上的一个回答——“ How deep are your unit tests? ”。一个有13.8K的分的人（ John Nolan ）问了个关于TDD的问题，这个问题并不新鲜，最亮的是这个问题的Best Answer，这个问题是—— “TDD需要花时间写测试，而我们一般多少会写一些代码，而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了，这会不会太过分了？那么，我们写单元测试的这个单元的粒度到底是什么样的？并且，是不是我们的测试测试得多了点？” 答案 StackOverflow上，这个问题的答案是这样的—— “I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong