读完了讨论复杂度的章节（《UNIX编程艺术》），被教导两个原则：
1，复杂度在所难免，除去代码量这种太过直观的衡量不说，人类更倾向于降低实现复杂度，而非接口复杂度。
2，各种分离的接口模式仍然适用，但是如果实在不能完成渴望的功能，才考虑集成到一个IDE下。

软件课程要做的game项目进展得比较顺利，由于已经有了一个demo，得以熟悉game软件大体的框架，此外UML恰当的运用到设计中，使得各种对象间的接口问题得以轻松解决。
不过，team work的一个基本前提，就是“认识一致”吧。如果某个partner没有了解到框架如何运作，那么写起代码来，应该是比较乏味的。
经验有1，无耦合的对象间交互。一个对象，尽可能不包含以其他对象作为实参的成员函数。前一个demo就是违反了这点，结果接口设计以及实现都不厌其烦。所有的对象交互问题都离开对象本身，而丢到一个processor里面，由processor根据两对象的类型，驱动对象的恰当方法，完成交互。
目前的麻烦也有1个：

如上，关键是我现在不能过多预料它们的生存期问题。resource manager最长，但是有可能some thing的时间要比some work processor短。如何解决？