3. 模块化，对象和状态
即使它变了，但它还在。
前面的章节介绍了编程需要的基本元素。我们看到了原生的程序和原生的数据
是如何组装成复合的实体的，并且我们学到了在帮助我们对付大系统的复杂性
方面抽象是极为重要的。但是这些工具对于设计程序是不够的。高效的程序
这种人工产物也需要有组织原则来指导我们对编程设计的全过程进行规范化。
尤其是我们需要帮助我们对大系统进行结构化的策略，为了这种系统将被模块化，
为了它们能够被自然地分解成独立的部分，被单独地开发与维护。
一种强有力的设计策略，尤其适合于模型化的物理系统的程序的构建，
我们的程序的结构是基于被模型化的系统的结构。对于在系统中的
任一个对象，我们都相应地构建一个计算对象。对于任一个
系统动作，我们在我们的计算模型中定义一个符号操作。在使用这种策略之中，
我们的愿望是为了容纳新的对象或者是新的动作的扩展模型时，不要求对程序
有策略性的修改，而仅仅是类似于那些对象与动作的新符号的增加。
如果在我们的系统组织中取得了成功，那么为系统添加一个新的特性，或者是
调试一个旧的功能，我们将不得不修改的地方 将仅局限于系统的一小部分。
为了一个大的扩展，我们组织起一个大的程序的方式是被我们的模型化的系统的
观念所支配的。在这一章中，我们将调查与研究两种主流的组织化的策略，
这些策略源于系统的结构的两种完全不同的视角。第一种组织策略聚焦于
对象，这种策略把一个大的系统看作是各不相同的对象的集合，这些对象的
行为可能随着时间的流逝而改变。另一个组织策略则聚焦于信息的流动，
更像是一个电气工程师看待一个信号处理系统一样。
基于对象的方法与流处理的方法在编程中，都能引起重大的语言学问题。
对于对象，我们必须关心的是一个计算对象都被如何改变和仍维护它的唯一性。
这将迫使我们放弃我们原有的计算的替换模型（在1.1.5部分），
转而支持一个更加机械化的更少理论性的易实现的计算的环境模型。
处理对象，改变，唯一性的难题是一个基本的在我们的计算模型中与时间
搏斗的需要的结果。当我们允许程序并发执行时这些难度将变得更大。
当我们需要把我们的模型中的模拟时间与在计算机的执行中发生的
事件的序列分离开来时，流方法最值得探索。我们将使用一种叫做
推迟执行的技术完成这个任务。