December 31, 2020

我们日常使用的网站、APP 的界面，可以由编程语言来进行描述和控制。

那么，一个建筑物，如果我们把它视为人和空间功能进行交互的界面，那么，似乎也可以由程序，或者一套规范的语言来描述。这给建筑设计带来了几方面突破的可能性：

1. 使用标准语言来描述建筑布局，再将其编译为图纸或者模型，使得建筑的信息从源头就得以存在，而且符合 Single Source of Truth 原则，同时还可以引入各种辅助、测试和优化的自动化工具。
2. 便于设计逻辑和通用组件的复用，不仅提高了工作效率，还能间接提高设计过程和成果的标准化。
3. 使用声明式的方式来描述建筑布局，将人的注意力从制图和排版，转移到了建筑功能的设计本身上，减少了重复劳动和无效思考。

下面具体说说我的想法。

组件

1. 建筑物中的每个功能元素，都可以视为一个组件（component）比如，门是一个组件，房间是一个组件，柱子是一个组件，当然，钢筋也可以视为一个组件。
2. 组件具有可配置的属性和行为例如，门组件，至少有高、宽两个属性，和一个附着在墙上并形成门洞的行为。属性可以指定，但同样地，行为也应该可以。比如，人防门需要指定在特殊情况下不开门洞，或在门洞周边设置门框柱等加强措施。
3. 组件之间可以产生关联和进行通信组件间因功能或者空间层次的不同，可以有各种各样的关联形式。常见包含、平级，也可能会有更复杂的依赖关系和逻辑联系。组件间通过互相通信或者共享全局数据，能自发地确定其自身的一些属性和行为，也方便人在设计逻辑的顶层对整个建筑设计方案进行调整。

以上三点，Revit 做到了 1，勉强做到了2，但 3 就几乎没有了。实际上，Revit 的族实例之间的通信方式极其贫乏，而且很多时候根本无法获取或发送数据，导致了大量重复性工作。吐槽结束！

范式

再说下声明式。与其相对的，是目前我们广泛应用的命令式。一个简单的例子：

命令式

去酒吧点一杯酒，指挥服务员：

• 从架子上取下一个玻璃杯；
• 把杯子放在酒桶前；
• 打开酒桶开关，直到酒杯满；
• 把杯子递给顾客；

这就是按照命令式点一杯酒的，需要告知服务员如何给顾客提供一杯酒。

声明式

告诉服务员，我要一杯酒即可。

显而易见，命令式的范式将所有的思考过程都放在了客人（设计师）这一端，而声明式则将这些工作都给了更专业的酒保（计算机）。