纸上得来终觉浅, 绝知此事要躬行
。警惕不要在不知不觉中把上层设计的逻辑引入到下层,如此会把下层代码的适用性限制在上层的环境中。例如要把上层的对象类型作为参数传给下层。
。不要忽略设计的可变性。比如有一个A类单例对象,函数f需要用到A的对象,于是在f的实现中A::GetInstance().... 如果明确无论在什么样的情况下类A 只能用单例来实现那就不用顾忌,如果在未来设计中类A会有多个对象,最好在f的参数表中加上一个A类型参数。需要A对象从外部传进来。
。不要间接把对用户隐藏的特定库的头文件引入到用户的代码中使用户不知不觉对这个库形成依赖。
。设计时候多想想用户可能会怎么使用这个类。
。设计类的时候尽可能不要对类暴露太多外部情况,类最好只完成本职工作,比如尽量不要让类有对外部对象的引用,如果需要知道外部信息最好找个方法避免类对外部的直接操作。
。需要类之间通信,又不想使类知道与它通信的对象的细节,可以使用消息机制。
。句柄类不仅可以隐藏类细节,并且可以对用户隐藏内存的管理。
。FSM( 有限状态机 )可以使设计变得灵活。
。内存池可以避免动态创建对象的时间开销、内存碎片、也可能改善数据的空间局部性。
。内存管理系统可以实现内存分配的管理,比如跟踪内存泄露。
。通常把对象交给对象管理器就减少了对于对象的部分控制。
。有些虚函数确实不必要,即使用到了虚函数,或许可以在不影响设计合理的情况下把需要抽象的部分合并到其他虚函数。