讀完了討論復(fù)雜度的章節(jié)（《UNIX編程藝術(shù)》），被教導(dǎo)兩個原則：
1，復(fù)雜度在所難免，除去代碼量這種太過直觀的衡量不說，人類更傾向于降低實現(xiàn)復(fù)雜度，而非接口復(fù)雜度。
2，各種分離的接口模式仍然適用，但是如果實在不能完成渴望的功能，才考慮集成到一個IDE下。

軟件課程要做的game項目進展得比較順利，由于已經(jīng)有了一個demo，得以熟悉game軟件大體的框架，此外UML恰當(dāng)?shù)倪\用到設(shè)計中，使得各種對象間的接口問題得以輕松解決。
不過，team work的一個基本前提，就是“認識一致”吧。如果某個partner沒有了解到框架如何運作，那么寫起代碼來，應(yīng)該是比較乏味的。
經(jīng)驗有1，無耦合的對象間交互。一個對象，盡可能不包含以其他對象作為實參的成員函數(shù)。前一個demo就是違反了這點，結(jié)果接口設(shè)計以及實現(xiàn)都不厭其煩。所有的對象交互問題都離開對象本身，而丟到一個processor里面，由processor根據(jù)兩對象的類型，驅(qū)動對象的恰當(dāng)方法，完成交互。
目前的麻煩也有1個：

如上，關(guān)鍵是我現(xiàn)在不能過多預(yù)料它們的生存期問題。resource manager最長，但是有可能some thing的時間要比some work processor短。如何解決？