*续 第五章弯曲，或折断
4 它只是试图
a) 以一个电子表格应用举例，除了显示表格，还要能把数值显示为柱状图，还有总计功能。实现的大概过程为：首先创建一个模型（数据自身），以及用于对其操纵的常用操作；然后创建不同的视图，以不同方式显示数据，作为表格、柱状图、总计框，每个视图都有自己的控制器。
b) 让视图与模型分离，可以用低廉的代价为自己换来许多灵活性，MVC是最为重要的维护可撤销性的途径之一。
c) MVC
模型，表示目标对象的抽象数据模型。模型对任何视图或控制器都没有直接的了解
视图。解释模型的方式。它订阅模型中的变化和来自控制器的逻辑事件。
控制器。控制视图、并向模型提供新数据的途径。它既向模型、也向视图发布事件。
（但MVC在Web应用中，受限于HTTP连接的特性，控制器无法向视图发布事件。）
d) 除了一般意义上的MVC，我们还可以超越GUI，组成模型-查看器网络。查看器对象可以是更高级对象的模型，而后者自己可能又是不同的格式化查看器的模型。
5 黑板
a) 关于黑板方法，可以用侦探的工作来举例。每个侦探都随时可以在黑板上增加各种事实、证人陈述等，以促成发现某些关联，最终破案。黑板方法有一些关键特性：
没有侦探需要知道其他任何侦探的存在
侦探可能接受过不同的训练，具有不同程度的教育背景和专业经验。但他们都渴望破案，这就是全部的共同点。
在这个过程中，不同侦探可能来来去去，并且工作班次也可能不同。
对放在黑板上的内容没有什么限制，可以是图片、判断、物证等。
基于计算机的黑板系统最初是为在人工智能中的应用而发明的，解决的问题大而复杂，如语言识别、推理系统等。现代的分布式类黑板（blackboard-like）系统有JavaSpaces和T Spaces等。
第六章 当你编码时
传统看法认为，项目一旦进入编码阶段，工作主要就是机械地把设计转换为可执行语句。但作者认为，这种态度是许多程序丑陋、低效、结构糟糕、不可维护和完全错误的最大原因。
编程不是机械工作。相反，编程时每一分钟都需要作出决策，如果要让程序享有长久、无误和富有生产力的“一生”，就必须对这些决策进行仔细地思考和判断。
不主动思考他们的代码的开发者是在靠巧合编程。
1. 靠巧合编程
a) 士兵起初没有探测到地雷，但这不过是侥幸，但他由此得出了错误的结论，认为这里没有地雷，最终导致了灾难性的结果。作为开发者，我们也工作在雷区中，应该保持警惕，不要得出错误的结论。我们应该避免靠巧合编程——依靠运气和偶然的成功——而要深思熟虑地编程。
b) 实现的偶然。实现的偶然是那些只是因为代码现在的编写方式才得以发生的事情，你最后会依靠没有计入文档的错误或是边界条件。
虽然靠巧合编程，但代码已经能工作，但这种做法很危险。因为它也许不是真的能工作，只是看起来能工作；而且我们依靠的边界条件也许只是一个偶然。在不同的情形下（比如不同的屏幕分辨率），它的表现可能就会不同；此外没有计入文档的行为可能会随着库的下一次发布而变化；而多余的和不必要的调用也会使你的代码变慢；多余的调用还会有引入新bug的风险。
对于你编写给别人调用的代码，要进行良好的模块化以及把实现隐藏在撰写了良好文档的小接口之后。
对于你调用的例程，要只依靠计入了文档的行为。
c) 语境的偶然。比如GUI，是否在依靠说英语的用户、有文化的用户，或者别的什么没有保证的东西。
d) 项目可以在所有层面上让人误入歧途，从生成需求直到测试。人们常常在头脑中带着许多假定，但这些假定很少被计入文档，而且在不同的开发者之间常常是冲突的。所以最好不要假定，而是要证明。
e) 怎样深思熟虑地编程
总是意识到你在做什么，不要做温水中的青蛙。
不要盲目地编程，试图构建你不完全理解的应用，或是使用你不熟悉的技术，就是希望自己被巧合误导。
一定要按照计划行事。
依靠可靠的事物，而不是巧合或假定。如果你不得不依靠假定，就依靠最坏的假定。
为你的假定建立文档。这有助于你澄清头脑中的假定，并把它们传达给别人。
不要只是测试你的代码，还要测试你的假定。不要猜测，要实际尝试它。编写断言测试你的假定。
为你的工作划分优先级，把时间花在重要的方面。
不要做历史的奴隶，不要让已有的代码支配将来的代码，随时准备好就进行重构。
下次如果有什么东西看起来能工作，而你却不知道为什么时，要确定它不是巧合。