面对这种情况，我也比较矛盾。的确，我可以采用不同的、更简单的方式实现这个接口（例如直接传ifstream和deque），但是扩展性呢？我昨天才说要在设计之初降低耦合，怎么能够走回头路呢？所以我坚持了，而且主动帮他补课，但我知道，要很好的理解这些事情还要点时间。
OK，无论如何，他似乎已经对上面这些技术问题有所了解，不过新的麻烦又来了。由于这个函数要实现的是分词，所以我们必须读取单个的字符，包括空格符和回车符，但是很可惜，用istream_iterator<char>得到的iterator并不能得到空格符和回车符，我们试了很多方法都不行。这回真的郁闷了……怎么办？如果要坚持这种设计，我可以考虑设计一种调用ifstream的get方法的iterator，这可行但似乎小题大做了，毕竟我并没有义务去扩展STL。麻烦麻烦麻烦！
接下来的时间里我一直在权衡，说实话，我不想放弃这种“完全没有耦合”的完美设计，但又不想在系统设计之初就开始构建自己的基础库，这似乎是一种经典的过度设计。嗯，不知不觉这一天就过去了！
回寝室的路上我好好的总结了一下自己的想法，我突然意识到一个严重的问题：ReadFile接口设计本身是不是就是一种过度设计？我真的需要如此之低的耦合度么？是的，我其实不需要这样复杂的设计！在可以预见的未来（甚至一直到项目结束），我们读取的介质都只是文件，ifstream其实完全足够；至于输出介质，我可以封装一个CWordQueue（直接把deque<string>重新定义了一次），让CReader和作坊工厂都依赖于CWordQueue，未来就算要进行某种扩展，只需要保证push_back意义不变的前提下重新实现CWordQueue就可以。
那么，新的接口可以这样表示：
class CReade
{
// ...
public:
bool ReadFile(istream &input, CWordQueue &output);
};
文章来源于领测软件测试网 https://www.ltesting.net/
