[导入]程序中的结构表达

　　循环结构是imperative language的重要组成部分，一般也是程序中比较难以理解的部分。特别是没有软件技术背景的朋友，明显对于循环的理解力较弱。在Von　 Neumann体系结构中，赋值语句是必须的，因而引出了存储概念，也引入了时间概念，因为我们可以区分出赋值前和赋值后的时刻。引入时间之后，本质性的 影响是程序串行化，而强迫我们从并行思考转入串行处理。很多时候这是一种不自然的情况，在我们的自然思维中，我们看到的或想到的也许只是一组静态结构，但 在程序中表达的时候却往往不可避免的需要引入一个动态过程。而我们控制动态结构的能力总是不足的。最近对于函数式语言及处理风格的越来越强烈的要求可能也 从侧面反映了大家对这种结构失配的不满。
　　　但是串行思维毫无疑问也是我们正常思维模式的一部分（当然这种思维模式在多大程度上是因为Von Neumann 体系造成的，也是个很有趣的问题）。例如在页面渲染的时候，我们可能希望预先把所有用到的数据都转载到内存中，赋予不同的变量名，然后在页面模板中我们只 要知道如何把这些数据变量表现出来就可以了。先做完A再做B，这是分层的思想，也是典型的串行思维。而基于数据进行处理，也是Von Nenuman体系的基本思想。但是如果处处要求预先计算并赋值，往往增加了很多额外的步骤(glue code)，并且增大了对内存（计算空间）的需求。分层之后，还存在着一个各个层次之间结构匹配的维护问题。
　　　面向对象在结构表达方面是一种 巨大的进步。经过多年的发展，我们在表达静态结构关系方面已经是驾轻就熟了。通过属性关联，我们可以沿着对象图进行结构遍历。如果使用成员函数，在这种遍 历过程中还可以包容更多的动态特性。而在数据持久化方面，ORM的盛行也在一定程度上证明了对象图的有效性。使用对象图可以大大降低对赋值语句的需求，减 轻了明确建模的压力（每一次赋值都要求着一个明确的变量名，一个概念），也缓解了Von Neuman体系结构的束缚。例如，我们不再需要
　var user = loadUser(userId);
  var userOrgnization = loadOrgnization(user.orgId);
  var userOrgnizationName = userOrgnization.name
而是直接使用　　user.orgnization.name

    目前面向对象所表达的大多数结构还是基于数据语义的，而我们对于函数等高阶结构的控制能力仍然较弱。设计模式在这方面提供了一些经验，但还是远远不够的。 在我们经验不多的时候，我们需要依赖于明确的实体数据，而在我们的理解逐步深入之后我们就可以通过Visitor, Iterator等模式支撑起整个结构。高阶结构比低阶结构难以控制，一方面是因为动态性本身比静态性难以理解，另一方面函数对信息的使用和流动是一种主 动约束,如果约束的不正确，会造成结构的失效。而数据的使用是完全开放的，很多决定都可以延迟到使用时刻决定。当然，开放性带来的问题也早就众所周知了： 不受限制的使用将导致无法控制的困境。在基础的数据层封装方面，一般我并不提倡大量使用domain model似的具有丰富语义的数据对象。因为数据是共享的，应该存在一个开放的数据层，在其上可以建立业务对象。混杂在一起会限制系统的演化。