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

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

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