我现在便可以对Tokenizer进行充分的单元测试，以确保它的功能满足我的要求。测试完成后，我就对它完全放心了。而此时，我的SearchCriteriaBinder便会直接使用Tokenizer对象，而不是内部的私有方法——当然，是基于抽象来的：
| public class SearchCriteriaBinder : IModelBinder { public SearchCriteriaBinder() : this(new Tokenizer()) { } internal SearchCriteriaBinder(ITokenizer tokenizer) { this.m_tokenizer = tokenizer; } private readonly ITokenizer m_tokenizer; public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) { var modelName = bindingContext.ModelName; var rawValue = bindingContext.ValueProvider[modelName].RawValue; var text = HttpUtility.UrlDecode(rawValue.ToString()); var tokenGroups = this.m_tokenizer.Tokenize(text); ... } } |
原本由私有的Tokenize方法负责的逻辑，现在已经委托给ITokenzier对象了，而这个对象可以在构造 SearchCriteriaBinder对象时通过构造函数提供。请注意，提供ITokenizer对象的构造函数访问级别是internal，也就是说，它可以被单元测试代码所访问（通过InternalVisibleToAttribute），但是无法被另一个程序集的使用方调用。也就是说，经过重构的SearchCriteriaBinder，它的可测试性提了，但是对外的表现却没有丝毫变化。
经过简单思考，便可以发现这一简单的改变其实也较为满足SOLID原则中的一部分：
* 单一职责：SearchCriteriaBinder职责很单一，解析工作交由同样职责单一的Tokenizer进行。
* 依赖注入：这里使用了构造函数注入的方式，SearchCriteriaBinder对Tokenizer的依赖不是写死在代码里的。
* 接口分离：SearchCriteriaBinder并不直接访问Tokenizer，而是通过一个抽象（ITokenizer）使用的。
这便是我常用的“可测试性驱动开发”，我一开始只是按照惯例直接实现BindModel方法，然后发现一个需要测试的私有方法，因此为了提高可测试性，我将部分功能提取到独立的Tokenizer对象中去。在实际开发过程中，我也可能是直接在脑子里进行简单的分析，然后直接发现我们的确需要一个 Tokenizer方法（这点想象应该不难），于是直接实现ITokenzier接口，Tokenizer类以及单元测试。这样，可能 SearchCriteriaBinder从一开始就会变成目前的样子。不过更多的情况，的确是写着写着，为了“可测试性”而进行的重构。为了说明这个 “思路”，我接下来还是使用“编写代码——尝试测试而不能——重构”的方式来进行开发。
相关阅读：
