2月21日，專案正式開始第二天。
依照昨天設計的框架和介面，我們開始實現這些功能，不過似乎大家的進展都比較慢，特別是XophiiX，似乎他陷入了困境之中。
具體是什麼問題呢？請看下面的介面定義：

    class CReader
    {
        // ...
    public:
        template <class ForwardIterator, class InsertIterator>
        bool ReadFile(ForwardIterator &input, InsertIterator &output);
    };

為了讓ReadFile儘量的通用並且完全不依賴於輸入和輸出的具體介質，我們把ReadFile設計成模板方法，入口引數是輸入和輸出的iterator。實際上，input接受的是istream_iterator<char>，output接受的是一個deque的inserter。這件事本身應該還不算艱深，只是XophiiX原來並沒有關注過iterator的用法，不瞭解inserter的重大作用，也不清楚模板的成員方法如何實現，使得他實現這個介面時非常鬱悶，只好慢慢的翻C++ Primer。
面對這種情況，我也比較矛盾。的確，我可以採用不同的、更簡單的方式實現這個介面（例如直接傳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);
    };

我相信這個介面應該可以穩定到專案結束，其實這已經足夠了。嗯，明天我一定要為自己的過度設計向大家道歉，如果不是因為這個煩人的介面，XophiiX也不會那麼鬱悶了。過度設計，讓它離的更遠些吧。