1.如何封装？
封装总被提及，但是封装除了隐藏细节，还有什么需求呢？封装不仅仅是有简化过的模型看到复杂的概念，而且同时还不能让你看到复杂概念的任何细节。隐藏信息的重要性毋庸质疑。所以我们现在不仅用 C++ 的 private 隐藏信息。还用接口的方法，不在头文件暴露任何设计细节。另外，任何一个不满足现状的程序员，对自己以前的代码一定不会满意。但是复用老的不满意的代码并非坏事。我们需要做的是，重用的时候，把老的东西隐藏起来。
2.防御性编程是什么?
防御式编程的主要思想是：子程序应该不因传入错误数据而被破坏，哪怕是有其他子程序产生的错误数据。简单点讲就是容错性。
要点：
最终产品代码中对错误的处理方式要对“垃圾进，垃圾出”复杂得多。
防御式编程技术可以让出错误更容易发现、更容易修改，并减少错误对产品代码的破坏。
断言可以帮助人尽早发现错误，尤其是在大型系统和高可靠性的系统中，以及快速变化的代码中。包含C++
、Java和Microsoft Visual Basic在内的很多语言都支持断言，比如C++中标准的aasert宏并不支持文本消息。
3.耦合的种类有哪些？
松散耦合是每个系统设计人员所追求的东西。但是其标准往往把握不准。举个简单的例子，不一定恰当。在我最早的设计里，系统把坐标这个东西封装成一个叫做 point ，以后参数传递都传 point * ，而不是 x,y 。这看使很合理。但是，这的确增加了耦合度。因为每个类都需要知道 point 的细节。很多情况下，用简单类型做参数传递反而更合适。(到底传 point * 还是 x,y 依旧要根据实际情况靠量) 参数过多也会导致耦合度的增加，从这个角度看，x,y 是两个参数， point * 是一个参数。关于耦合程度的问题，没有绝对唯一的标准。
4.需求分析如何做？
其实我们不必去照本宣科的写需求分析书什么的，做需求分析即使是在大脑中，口头交流上完成，也是有这么一个过程。落下文字固然是好的，但并不是重点。关键在于做不做。是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率。是否详细定义了系统全部输出，包括目的，精度，取值范围、出现频率，格式？是否定义了机器内存和剩余磁盘空间的最小值？是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件的接口的变更能力？ 书中列的远比我这里列出的多，非常值得一读。定下这些是很重要的，我觉得合理的游戏开发，是有一个相对稳定的策划方案，和一些已经完成完成的美术资源。大部分的变更都留在下一版本去做。策划和美术永远为下一个版本工作，而程序可以根据相对稳定的需求做设计。这样做，即使第一个版本是不可玩的，扔掉，也是能让游戏最终成功。
5.怎么写一个高质量子程序？
子程序代码长度最好控制在200行之内，如果超过200行，会在可读性方面遇到问题。
把宏表达式整个包含在括号内，比如：#define Cube(a) (a*a*a)
创建子程序最主要的目的是提高程序的可管理性，当然也有其他一些好的理由。其中，节省代码空间只是一个次要原因：提高可读性、可靠性和可修改性等原因都更重要一些。
子程序可以按照其内聚性分为很多类（功能内聚、顺序内聚、通讯内聚、临时内聚过程内聚、逻辑内聚、巧合内聚），而你应该让大多数子程序具有功能上的内聚性，这是最佳的一种内聚性。
子程序的名字是它的质量的指示器。如果名字槽糕但是恰如其分，那就说明这个子程序设计得很差劲。