如果许多个体有着共同的名字，那么我们可以认为它们同样有着相应的概念或形式—明白我所说的吗？
明白。
让我们以任意一个普通的事物为例。我们的世界中有许许多多的床和桌子，是吗？
是的。
但这里仅仅存在两个它们的概念或形式：一个是床的概念，一个是桌子的概念。
确实如此。
而任何工匠都是遵循这种概念来制作我们所使用的床和桌子的。
—柏拉图（公元前360年），《理想国》第十卷
在2008年的第7届设计思想研讨会上，每个发言人都对四个同样的设计小组会议作报告。3 视频和打印件都提前很好地分发下去了。
来自雷丁大学的Rachael Luck在架构会谈中提出一个之前没有引起任何人注意，而后又被大家一致认同的实体：设计概念。
毫无疑问，架构师和客户总是不断提到这一共享的不可见的实体。演讲者时常会对着画面作出各种含糊的手势，但显然他们并不是在指向画面的某一部分或者那其中的某一特定事物。通常，他们所关注的是开发中的设计概念的完整性。
Luck的见解让设计概念拥有了其自身的地位，这于我本人的经验有着强烈的共鸣。在开发IBM System/360大型计算机家族的单一架构的时候（1961～1963），尽管从来没有正式命名过，但这样的实体始终存在于架构小组内部。得益于Gerry Blaauw的远见卓识，我们将System/360的设计活动明确地分成了架构、履行和实现三个部分。其基本思想是整个计算机家族对程序员呈现统一的接口，即架构；而根据性能和价格的不同可以有多个并行的实现（见第24章）。
多个实现的同时性伴随着几个工程经理的竞争，这些驱动着形成一个统一漂亮的架构，并且避免了为节约成本而作出较小的妥协。然而这种力量仅是来自于架构师们的本能和愿望，他们每个人都想做出一台漂亮的机器。
随着架构设计的不断发展，我发现了一件乍一看很奇怪的现象。对于架构小组而言，真正的System/360是设计概念本身—一台柏拉图式的理想机器。那些在工程车间建造中的机械式的或电子的Model 50、Model 60、Model 70和Model 90等，只不过是模仿那台真正的System/360的柏拉图式机器的影子。真正System/360的最完整最忠实的体现，不在那些以硅、铜或者钢的形式组成的物理计算机上，而是存在于《IBM System/360操作原理》这本程序员的机器语言手册的文字和图表里。
后来在View/360海滨小屋（见第21章）的建造中，我也有类似的体验。它的设计概念在构建活动开始的很早以前就已经成型。历经了许多版本的绘图与纸板模型搭建，其概念始终贯穿 其中。
非常有趣的是，我从未在OS/360软件家族中感觉到这样的设计概念实体。也许它们的架构师有这种感受，又或许我对其概念框架的理解还没有到了如指掌的程度。也许设计概念没有在我这里萌发的一个原因是OS/360实际上是分别由四个部分混合而成的：一个主控制器、一个调度器、一个I/O控制器以及一个庞大的编译器和实用工具软件包（见第25章）。
价值何在
在设计对话中将不可见的设计概念转化为真正的实体是否会带来积极的价值呢？我认为是的。
首先，良好的设计具有概念性的完整性—统一、经济、清晰。它们不仅可以工作，而且能带来快乐，正如维特鲁威首次阐述的那样。我们使用诸如优雅、利落、漂亮这样的术语来形容桥梁、奏鸣曲、电路、自行车、计算机以及iPhone。辨析出设计概念这样一个实体，可以帮助我们在自己独自设计时去追寻这种完整性，有助于在团队设计时围绕这一概念一起工作，也有助于将它传授给年轻人。
其次，以这样的方式经常提及设计概念，对于一个设计团队内的沟通有极大的帮助作用。概念的统一是一种目标，它只有通过大量的对话才能达到。
就设计概念本身而言，比起由它衍生而出的表达或是部分细节，会话要直接得多，也是焦点所在。
因此，电影制片人使用故事板来保持其设计会话始终关注设计概念而不是实现细节。
关注细节，当然就会将不同版本的概念之间的冲突暴露出来，并迫使其得到解决。例如，System/360架构需要一个十进制数据类型，以桥接拥有成千上万用户的IBM十进制机器。我们所开发的架构中已经有了几个数据类型，包括32位的定点补码整数和可变长的字符串。
十进制数据类型可以被定义成类似于这两者当中的任意一个。那么哪一个才更适合System/360的设计概念呢？两方面对此都拿出了强有力的论据，这背后的力量直接依赖于个人对于设计概念不同的理解。一些架构师脑海中的设计概念反映的是早期的科学计算机，而其他架构师脑海中的概念反映的是早期的商务计算机。System/360有明确的设计目标，对于这两种应用都应提供良好的支持。
我们选择以字符串数据类型为基础来建模十进制数据类型，对于绝大部分特定的十进制数据类型用户群体，即IBM 1401的用户来说，这是最熟悉的数据类型。如果再给我一次机会，我仍会做出这样的决定。
明白。
让我们以任意一个普通的事物为例。我们的世界中有许许多多的床和桌子，是吗？
是的。
但这里仅仅存在两个它们的概念或形式：一个是床的概念，一个是桌子的概念。
确实如此。
而任何工匠都是遵循这种概念来制作我们所使用的床和桌子的。
—柏拉图（公元前360年），《理想国》第十卷
在2008年的第7届设计思想研讨会上，每个发言人都对四个同样的设计小组会议作报告。3 视频和打印件都提前很好地分发下去了。
来自雷丁大学的Rachael Luck在架构会谈中提出一个之前没有引起任何人注意，而后又被大家一致认同的实体：设计概念。
毫无疑问，架构师和客户总是不断提到这一共享的不可见的实体。演讲者时常会对着画面作出各种含糊的手势，但显然他们并不是在指向画面的某一部分或者那其中的某一特定事物。通常，他们所关注的是开发中的设计概念的完整性。
Luck的见解让设计概念拥有了其自身的地位，这于我本人的经验有着强烈的共鸣。在开发IBM System/360大型计算机家族的单一架构的时候（1961～1963），尽管从来没有正式命名过，但这样的实体始终存在于架构小组内部。得益于Gerry Blaauw的远见卓识，我们将System/360的设计活动明确地分成了架构、履行和实现三个部分。其基本思想是整个计算机家族对程序员呈现统一的接口，即架构；而根据性能和价格的不同可以有多个并行的实现（见第24章）。
多个实现的同时性伴随着几个工程经理的竞争，这些驱动着形成一个统一漂亮的架构，并且避免了为节约成本而作出较小的妥协。然而这种力量仅是来自于架构师们的本能和愿望，他们每个人都想做出一台漂亮的机器。
随着架构设计的不断发展，我发现了一件乍一看很奇怪的现象。对于架构小组而言，真正的System/360是设计概念本身—一台柏拉图式的理想机器。那些在工程车间建造中的机械式的或电子的Model 50、Model 60、Model 70和Model 90等，只不过是模仿那台真正的System/360的柏拉图式机器的影子。真正System/360的最完整最忠实的体现，不在那些以硅、铜或者钢的形式组成的物理计算机上，而是存在于《IBM System/360操作原理》这本程序员的机器语言手册的文字和图表里。
后来在View/360海滨小屋（见第21章）的建造中，我也有类似的体验。它的设计概念在构建活动开始的很早以前就已经成型。历经了许多版本的绘图与纸板模型搭建，其概念始终贯穿 其中。
非常有趣的是，我从未在OS/360软件家族中感觉到这样的设计概念实体。也许它们的架构师有这种感受，又或许我对其概念框架的理解还没有到了如指掌的程度。也许设计概念没有在我这里萌发的一个原因是OS/360实际上是分别由四个部分混合而成的：一个主控制器、一个调度器、一个I/O控制器以及一个庞大的编译器和实用工具软件包（见第25章）。
价值何在
在设计对话中将不可见的设计概念转化为真正的实体是否会带来积极的价值呢？我认为是的。
首先，良好的设计具有概念性的完整性—统一、经济、清晰。它们不仅可以工作，而且能带来快乐，正如维特鲁威首次阐述的那样。我们使用诸如优雅、利落、漂亮这样的术语来形容桥梁、奏鸣曲、电路、自行车、计算机以及iPhone。辨析出设计概念这样一个实体，可以帮助我们在自己独自设计时去追寻这种完整性，有助于在团队设计时围绕这一概念一起工作，也有助于将它传授给年轻人。
其次，以这样的方式经常提及设计概念，对于一个设计团队内的沟通有极大的帮助作用。概念的统一是一种目标，它只有通过大量的对话才能达到。
就设计概念本身而言，比起由它衍生而出的表达或是部分细节，会话要直接得多，也是焦点所在。
因此，电影制片人使用故事板来保持其设计会话始终关注设计概念而不是实现细节。
关注细节，当然就会将不同版本的概念之间的冲突暴露出来，并迫使其得到解决。例如，System/360架构需要一个十进制数据类型，以桥接拥有成千上万用户的IBM十进制机器。我们所开发的架构中已经有了几个数据类型，包括32位的定点补码整数和可变长的字符串。
十进制数据类型可以被定义成类似于这两者当中的任意一个。那么哪一个才更适合System/360的设计概念呢？两方面对此都拿出了强有力的论据，这背后的力量直接依赖于个人对于设计概念不同的理解。一些架构师脑海中的设计概念反映的是早期的科学计算机，而其他架构师脑海中的概念反映的是早期的商务计算机。System/360有明确的设计目标，对于这两种应用都应提供良好的支持。
我们选择以字符串数据类型为基础来建模十进制数据类型，对于绝大部分特定的十进制数据类型用户群体，即IBM 1401的用户来说，这是最熟悉的数据类型。如果再给我一次机会，我仍会做出这样的决定。