面對這種情況，我也比較矛盾。的確，我可以采用不同的、更簡單的方式實現這個接口（例如直接傳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);
};
文章來源于領測軟件測試網 http://www.kjueaiud.com/
