摘要：面向对象是当前程序设计的重要方法，也是描述现实问题的有效思想，通过对面向对象在参数化建筑设计中的两个应用实例的介绍，进而阐释其优势及应用潜力。
关键词：面向对象 参数化设计 面向过程 音乐厅设计
1.程序设计中的“面向过程”与“面向对象”
参数化设计是当代重要的建筑设计方法，能够帮助建筑师获得多解的设计方案，创造新奇的建筑形体，减轻工作负担。在参数化设计中，“将建筑看作众多外部及内在因素综合作用的复杂系统”，把影响设计的因素看成参变量，通过计算机语言构筑参数间的一系列作用规则（即“规则系统”），建立参数化模型，进而生成建筑体量、空间或结构，并可通过改变参变量获得多解动态的设计方案。在这一过程中，“规则系统”的构筑是核心步骤，而要精确地抽象并描述“规则系统”则必须依赖于合适的计算机语言，因此参数化设计必然要学习参照计算机程序设计中的思想方法。
在计算机程序设计中，“面向过程”和“面向对象”是两种最重要的思想方法。“面向过程”（Procedure Oriented）是一种以过程为中心的编程思想，起源较早，它的核心思路是分析出解决问题所需要的步骤，然后通过编写函数分别实现这些步骤，使用时依次调用函数从而解决整个问题。这种方法思路清晰，能够有效应对许多问题。然而随着性能的不断提高，计算机被用于解决越来越复杂的问题，“面向过程”逐渐无法胜任，随之而来的是“面向对象”思想方法的兴起。“面向对象”（Object Oriented）方法放弃了对过程的抽象，而将现实世界看成一个相互关联、相互作用的复杂系统，系统中的事物被抽象成“对象”（Object），相似的对象从属于“类”（Class），对象的特征用“属性”（Attribute）标示，相互关系则被抽象成“消息”（Message）与“方法”（Method），进而实现对整个系统的抽象与建模。时至今日，面向对象已不仅仅是一种编程方法，更是我们抽象与描述问题的新视角。
以上两种编程思想均能应用于参数化建筑设计，下面通过一个简单的例子说明它们的应用方法与特点。
2.应用案例
2.1应用案例1：不规则立面开窗
解决以上问题的常规思路是采用“面向过程”的方法，逐一添加随机尺寸的窗户，每添加一个窗户都与立面边界和既有窗户进行重叠检测，如重叠则以随机比例缩小窗户，直到其与立面边界和其他任何窗户都不重叠为止（图3）。这种方法能生成一些符合要求的方案，但也可能出现无解的情况：如图4所示，由于既有窗户的尺寸过大侵占了其他窗户的“空间”，后续窗户无法在1-5m的范围内选择尺寸避免与其重叠，导致了无解。可见，这一看似简单的问题却很难采用“面向过程”的方法进行抽象与描述。
2.2应用案例2：音乐厅参数化设计模型
2.2.1基于“面向过程”方法的音乐厅参数化模型
以上步骤忠实地反映了音乐厅的设计过程，获得了能够“一改皆改、智能联动”的参数化模型，部分实现了原本的设想，但同时也暴露了以下问题。
除此之外，程序编写中所涉及的构件需要依赖于其上游的构件参数或信息，导致程序的书写思路错综复杂，难以梳理；任何一个参数发生更改，哪怕是微小的局部修改都要对整个系统进行刷新计算。程序的执行效率较低。
2.2.2基于“面向对象”方法的音乐厅参数化模型
在使用面向过程方法“山穷水尽”后，笔者尝试采用面向对象的方法建立音乐厅参数化模型，其基本架构如下（图10）。
（1）定义“类”。本程序定义了音乐厅中最基本的六“类”构件，分别是“墙”类、“舞台”类、“门”类、“走廊”类、“包厢”类和“座椅”类。它们都具有不同的属性和方法（图11）。
（2）定义“关联系统”。此处“关联”指的是某一对象执行某种方法后，其他对象需要相应执行的方法。例如，音乐厅中某一墙体的移动会使与它相邻的墙体相应地旋转和缩放，以保持墙体连续闭合；会使舞台相应地缩放，以保证位于厅堂内部；会使墙体上的门相应地移动，以保持门位于墙上；会使座椅重新排布，以适应新的厅堂形式等。类似地，我们需要对系统中任意两个类之间的“关联”进行定义，形成“关联系统”（图12）。在“不规则立面开窗”一例中，因问题比较简单，我们将“定义关联”的步骤作为“定义类”的一部分；而对本例，由于系统较为复杂，有必要将“定义关联”独立出来，使系统架构更加清晰。
（4）设计“事件响应”机制。当用户修改某一对象时，消息池会接收指令并向被修改对象发送相应的消息，令其完成用户指定的操作。操作完成后，消息池会向“关联系统”发送消息，“关联系统”按照对象间的关联回馈其他对象所应相应执行的方法，消息池再令这些对象执行该操作。操作完成后再向“关联系统”询问下一步应该相应执行操作的对象。事件响应机制如“链式反应”般传递下去，直到没有对象需要执行操作为止，这时便完成了对整个系统的修改（具体的机制见图14，修改结果见图15）。正是通过这种“链式反应”般的传递响应机制，我们只需定义好系统中每两个类之间的“关联”，即可完成对系统中所有对象相互关系的描述，进而拼合出整个系统的规则。
另外，由于我们希望用户能够直接对系统中的任意建筑构件进行更改操作，因此必须建立“用户交互系统”接收用户的指令。因其与面向对象的方法关系不大，不在此详述。
由以上几部分组成的基于“面向对象”方法的音乐厅参数化模型克服了基于“面向过程”方法模型的问题与不足，其优势体现在以下几方面。
（1）模型具有相当大的修改灵活性。使用“面向对象”方法描述规则系统，只需枚举清楚任意两个类之间的关系即可涵盖系统的所有可能性，不会出现“组合爆炸”的情况（系统的可能性总数等于任意两个类之间的关系可能性数量相加，而不是乘积），因此编程量较小，以一个模型涵盖多种音乐厅类型具有可实现性（图16）。
（2）由于系统不存在“等级次序”，无论用户对构件进行何种修改，系统都能进行相应的改变。这样的使用方式更贴近设计过程，交互性强，使得模型有可能被用于方案推敲阶段。
除此之外，相较于“面向过程”的方法，基于“面向对象”方法开发的模型思路更为清晰，容易拓展；局部修改只需重新计算相关部分而不需要刷新整体，程序效率更高。
由此可见，在“建立音乐厅参数化设计模型”这一较为复杂的问题中，“面向对象”方法的优势是明显的。事实上，当我们采用“面向对象”方法解决其他复杂建筑问题时，以上优势仍然会存在。因此，我们应将“面向对象”视作抽象和描述建筑规则系统的有力方法，在未来的参数化设计中进行更为广泛的尝试和应用。
3.结论与展望
总体来看，相比“面向过程”方法，在参数化设计中使用“面向对象”方法能够对建筑这一复杂系统的规则进行更精准的抽象与描述，使程序具有更强的灵活性、更友好的用户交互性、更清晰的思路以及更高的执行效率。因此，这种方法在参数化设计中具有很强的应用潜力。
根据文中的两个实例我们不难归纳得到一套通用的程序架构（图17），基于这套架构我们能够使用面向对象方法精确地描述复杂建筑问题的规则系统。未来可以此为基础，开发针对某一特定建筑类型的参数化设计工具。以笔者研究的音乐厅为例，虽然不同音乐厅的外形与空间形式存在差异，但它们却都遵循类似的功能要求和技术规范，这正是参数化设计语境中的“规则系统”。基于面向对象的方法能够对其进行精确描述，并在完善用户交互、异常处理机制等辅助系统后。使得设计师可对建筑的任意构件进行修改，整个方案都能按照“规则系统”的设定进行相应调整，从而保证方案满足功能、技术等各方面的要求，同时减少设计师重复修改的工作量。这一思路使参数化设计能够获得更贴近实际建筑设计流程的应用。
