上一篇我们编写了第一个测试代码，我们再来看一下我们的 US, 测试备注 和 设计
US:我希望可以给定一个包含m元素对象的集合，给定我想从中选出的元素个数n，从中找出所有满足条件的元素组合列表(无序) C(n,m) 或 排列列表(有序) P(n,m)
设计
2、类库内包含 ComposerSelector<T> 和 PermutationSelector<T> 两个类
3、两个类都包含了 T[] SourceObjects 属性和 int CountToSelect 属性，来存储数据源和要从中取出的排列组合要包含的项目个数
4、我希望在给定这些值后，可以调用DoProcess方法来进行排列组合的运算
5、我希望运算成功后，可以在对象的Result属性读取到对应的结果
从之前的设计中，可以看到，ComposerSelector 和 PermutationSelector 有完全相同的属性和方法，我们就要考虑采用什么形式进行抽象
SourceObject 、 CountToSelect 和 Result 属性，在两个类中会具有完全相同的特性、可访问性和具体含义，显然如果采用接口抽象并不合适，将其放在一个Selector<T>的基类中会更合适，也许需要重构一下设计了
需要增加一个Selector的基类
SourceObjects和CountToSelect属性应该在赋值之后不允许外部对其进行修改，应该是pirvate set的
SourceObjects和CountToSelect需要创建能够传入对应参数的构造函数来对其进行初始的赋值
Result属性石DoProcess计算的结果，也不允许在外部进行修改，也应该是 private set 的
希望在Selector后能有个属性，直接获取到返回的排列组合的条数，而不需要去再每次写 selector.Result.Coun()
重构后的设计
2、类库内包含 ComposerSelector<T> 和 PermutationSelector<T> 两个类
这些设计，已经改变了代码的一些外部行为，因此需要重构的测试代码。
ComposerTest 类
public void TestCreateComposerSelector()
{
ComposerSelector<GenericParameterHelper> generalSelector = TestCreateComposerSelector<GenericParameterHelper>( new GenericParameterHelper[] { }, 5);
ComposerSelector< int> intSelector = TestCreateComposerSelector< int>( new int[] { }, 10);
ComposerSelector< string> stringSelector = TestCreateComposerSelector< string>( new string[] { }, 3);
ComposerSelector< object> objectSelector = TestCreateComposerSelector< object>( new object[] { }, 9);
}
private ComposerSelector<T> TestCreateComposerSelector<T>(T[] source, int countToSelect)
{
return new ComposerSelector<T>(source, countToSelect);
PremutationTest 类
public void TestCreateComposerSelector()
{
ComposerSelector<GenericParameterHelper> generalSelector = TestCreateComposerSelector<GenericParameterHelper>( new GenericParameterHelper[] { }, 5);
ComposerSelector< int> intSelector = TestCreateComposerSelector< int>( new int[] { }, 10);
ComposerSelector< string> stringSelector = TestCreateComposerSelector< string>( new string[] { }, 3);
ComposerSelector< object> objectSelector = TestCreateComposerSelector< object>( new object[] { }, 9);
}
private ComposerSelector<T> TestCreateComposerSelector<T>(T[] source, int countToSelect)
{
return new ComposerSelector<T>(source, countToSelect);
编译：失败（这是肯定的）
我们下面就来调整代码使创建对象的测试能够通过
ComposerSelector类
{
public ComposerSelector(T[] sourceObjects, int countToSelect) { }
}
PremutationSelector类
{
public PremutationSelector(T[] sourceObjects, int countToSelect) { }
}
编译成功
测试通过
然而，这时候的代码还远远没有达到设计的要求，接着就逐条解决
3.ComposerSelector<T> 和 PermutationSelector<T> 是 Selector<T> 的子类
这一条，并不不改变类的外部行为，根本不需要改变测试代码只需要创建一个基类并在子类中继承基类
我不希望能够直接创建Selector的对象，因此将Selector类标记为Abstract
修改后的 PremutationSelector类
{
public PremutationSelector(T[] sourceObjects, int countToSelect): base(sourceObjects,countToSelect) { }
}
PremutationSelector类就不给出代码了，你可能又发现了可以重构的地方了吧，不过当时我并没有发现这个，我是在后来代码有了更多的行为后，才发现了需要做构造方法的重构的，所以，这里我并不解决它，会在后面对其进行重构，在早起，过多的应用重构还有过度使用设计模式，也许会让你陷入一个泥潭。要知道，我们现在连一行具有实际意义的行为代码都没写。
编译成功
测试通过
下一条设计
4.Selector<T> 包含了 T[] SourceObjects 属性和 int CountToSelect 属性，来存储数据源和要从中取出的排列组合要包含的项目个数
这一条，就明显的需要来构建测试代码来进行测试了，这两个属性，都有读写的操作
属性写操作将会在构造函数内被执行
而读操作则需要我们进行读取操作来覆盖，下面就来编写测试代码
模拟从给定0-9十个数字中选出4个元素的Selector（ComposerSelector和PremutationSelector）
为了测试我们的设计能否应对更复杂的情况，我们再创建一个从一个包含有整型数字、字符、字符串、浮点、bool等不同类型对象的object的数组中选出三个元素的Selector（ComposerSelector和PremutationSelector）
ComposerTest 新增代码
public void ComposerPropertiesTest() {
int[] intSource = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int intCountToSelect = 4;
ComposerSelector< int> intSelector = new ComposerSelector< int>(intSource, intCountToSelect);
Assert.AreEqual(intSelector.SourceObjects, intSource);
Assert.AreEqual(intSelector.CountToSelect, intCountToSelect);
object[] objSource = new object[] { 10, ' A ', " HelloWorld ", 2.69f, true };
int objCountToSelect = 3;
ComposerSelector< object> objSelector = new ComposerSelector< object>(objSource, objCountToSelect);
Assert.AreEqual(objSelector.SourceObjects, objSource);
Assert.AreEqual(objSelector.CountToSelect, objCountToSelect);
}
编译：失败
下面要做的就是在Selector<T>类中增加对应的属性，并在构造函数中增加赋值行为，来使测试可以通过。
Select<T> 类：
public int CountToSelect { get; private set; }
public Selector(T[] sourceObjects, int countToSelect){
this.SourceObjects = sourceObjects;
this.CountToSelect = countToSelect;
}
编译：成功
测试：通过
虽说这个时候代码覆盖率已经100%了（因为PremutationSelector的构造行为和这两个属性的相关操作在基类中已经被完成，因此已经被ComposerSelector的测试代码覆盖）
我仍旧固执的为PremutationSelector编写了测试代码（这让人很痛苦，一模一样的代码的复制黏贴，但这会更增加对其重构的决心。如果对重构抱有偏执，恭喜，这就是重构的原因之一，写测试代码遇到的让人蛋疼的事情，在编写功能代码的时候，几乎会100%遇到。）
其实，这个问题，早在编写构造函数的测试代码时候，就碰到了，但我仍旧把对代码的重构，放在了完成我们对修改的设计进行完整的编码后才进行的。
继续
5.ComposerSelector<T> 和 PermutationSelector<T> 对象，可以调用DoProcess方法来进行排列组合的运算
目前为止对DoProcess的行为，还是只定义为依据给定的数据，进行运算，并且把结果存入Result属性。
只需修改测试，调用DoProcess方法即可，可以发现，原来测试方法中的ComposerPropertiesTest和PremutationTest方法中已经做过了创建的操作，因此，只需要修改这个测试方法，加入调用方法即可。
编译：失败
目前的类中还没有DoProcess方法，肯定无法编译通过，只要简单的加入一个DoProcess方法就可以使其通过运行了。
目前 ComposerSelector<T> 和 PermutationSelector<T> 在DoProcess 方法上就有了差别，一个是求组合，一个是求排列。
DoProcess会在所有的Selector中都需要有的方法，将其放在抽象基类中，然后在子类对其实现。
Selector<T> 中新增
ComposerSelector<T> 和 PermutationSelector<T> 中新增
{
}
编译通过
测试成功
这个时候，可以查看代码覆盖率，仍旧是100%，但是，目前还不能够在测试代码中对各个对象的DoProcess进行Assert来确定其是否在正确的位置被正确的执行，目前还不去具体实现算法，因此这个问题后面再解决。
6、Selector<T> 包含了 Result 属性，这个属性用来存储 DoProcess 方法运算后的结果值
初步一看，这一条包含了两条信息在里面
一，Selector<T> 包含了 Result 属性
二，DoProcess 方法运算后会将结果存入Result
再分析一下，Result 应该是只能通过调用DoProcess方法来改变其值，对外部只读。（当然这里因为我们缺少用户方，也可以说我自己就是用户，因此，我可以自己按自己的想法来设定。如果在正式工作中，应该与用户沟通以确定各个细节的对外特性）
三，Result 的 set 方法应该是 private
继续分析，
ComposerSelector<T> 和 PermutationSelector<T> 在DoProcess方法执行之后，Result 的值会不同，也有一些情况会出现相同的值的情况，视SourceObjects和CountToSelect值而定。
依据我们的上面三条分析结果
一，Selector<T> 包含了 Result 属性
二，DoProcess 方法运算后会将结果存入Result
三，Result 的 set 方法应该是 private
只要对给对应的selector加入Result 的读取操作就可以了，而Result的写操作会在DoProcess被覆盖。
在ComposerTest和PermutationTest测试方法内增加对DoProcess方法的调用和对Result方法的读取
ComposerTest 类内
public void ComposerPropertiesTest() {
int[] intSource = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int intCountToSelect = 4;
ComposerSelector< int> intSelector = new ComposerSelector< int>(intSource, intCountToSelect);
intSelector.DoProcess();
Assert.AreEqual(intSelector.SourceObjects, intSource);
Assert.AreEqual(intSelector.CountToSelect, intCountToSelect);
Assert.IsNotNull(intSelector.Result);
object[] objSource = new object[] { 10, ' A ', " HelloWorld ", 2.69f, true };
int objCountToSelect = 3;
ComposerSelector< object> objSelector = new ComposerSelector< object>(objSource, objCountToSelect);
objSelector.DoProcess();
Assert.AreEqual(objSelector.SourceObjects, objSource);
Assert.AreEqual(objSelector.CountToSelect, objCountToSelect);
Assert.IsNotNull(objSelector.Result);
}
PermutationTest内代码相同（我现在有了更多的重复代码,你应该已经嗅出了bad smell了,重构的理由更加充分）
编译：失败
在Selector<T>中添加Result属性即可；
Selector<T> 类中添加
编译:成功
测试会有两条失败信息：
未通过 ComposerPropertiesTest MathLibraryTest Assert.IsNotNull 失败。
未通过 PremutationPropertiesTest MathLibraryTest Assert.IsNotNull 失败。
这是并没有在DoProcess方法对结果进行赋值引发的测试失败。
这点我们在第二条已经考虑到了。
第二条并不改变测试代码，但是需要我们在DoProcess方法添加对Result的赋值来覆盖Result的set;
为了能够更好的测试，在DoProcess中，将SourceObjects存为Result中的一条结果，这样，就可以使用equals方法来测试Result是否被正确赋值
第三条无需多说吧
我们分别在ComposerSelector和PermutationSelector的DoProcess方法中加入伪实现的代码;
编译：失败
一点失误，由于子类的Result属性继承于基类，而对基类Result的set方法的private造成了子类也无法对其赋值。
只需要将基类内Result的set方法设为protected即可
修改代码
编译：通过
测试：通过
2、类库内包含 ComposerSelector<T> 和 PermutationSelector<T> 两个类
============待续================
到了这里，测试代码可以通过运行，而且覆盖率也很高 100% ，但是的测试代码内充满了让人恼怒的 bad smell 代码。
下一步，我并没有立即编写算法的代码，而是对测试代码和重构进行了简单的重构
这里我和一个朋友产生了争论，至今没有结果
对方说，我应该尽快地实现功能，在功能实现后再来进行重构，否则，我可能会耗费大量的工作在重构上而延缓了功能实现的时间（我同意，这的确会使功能实现的时间延后）
而我认为，这个时候，已经可以明显确定的设计上的缺陷，此时重构的成本最小，如果在完全实现功能后再重构，那么重构的工作量将会很大。
关于重构的时机，希望各位能够给些意见。