刘润最近在blog有一篇非常棒的文章（至少我很喜欢）：《形象化的能力》。今天我这篇就算是“形象化”（Visualize）能力的应用吧。 

任何解决方案都是由问题、以及问题所处的上下文决定的。熟悉设计模式的人可能会立即想到Christopher Alexander在其著作《模式语言》一书中为“模式”下的著名定义：

每个模式都是一个法则，有三部分组成。它表现的是一种特定的上下文、一个问题和一个解决方案之间的关系。

举个例子，把适配器（Adapter）设计模式的思维形象化表达出来。下图以“上下文-问题-解决方案”的形式对Adapter模式进行了归纳：设计所面临的问题来自我们希望使用某接口不兼容的类（或子系统）之时，而问题的上下文是这个接口不兼容的类是我们无法改变或不应改变的；最终通过“将无法修改的类（或子系统）封装成我们所需的接口”这样的设计解决了我们的问题，并且也符合上下文的限制性要求。

其实，生活中的例子更多。问题：需要一台电脑。理想化解决方案：买一台新的。上下文：资金有限。实际解决方案：买个二手的或者租一台。“头痛医头，脚痛医脚”、“囫囵吞枣”等成语典故也是对片面解决方案的讽刺。

更广泛、更实际而言，还有文化这只无形的大手的深刻影响。

 无需多说，看下面两则新闻。都是采取了“将照片公开”的“解决方案”，反响却很不同，这和文化不无关系：
女子地铁遭遇性骚扰 拍下色狼照片挂网上受质疑
纽约女子遭性骚扰网上公布色狼照片成民权英雄

 运用“上下文-问题-解决方案”思维也有助于理解《软件架构为谁而设计》的内容。总之，软件架构设计不能忽略“上下文”。所谓“上下文”就是和我们要解决的问题密切相关的一些条件和因素，既包括有利条件，也包括限制因素。简言之，上下文就是环境。进行设计时，只有充分利用有利条件、合理回避限制因素，最终的解决方案才是真正符合实际的。

对此，温昱的《软件架构设计》一书（已经交稿）有更多论述，毕竟，对需求分类、需求权衡、需求变化的深入研究，是软件架构师的“第一项修炼”。

发表于 @ 2006年11月24日　10:54:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:软件架构的精髓：协作（Booch语） | 新一篇:新书快评：脚本驱动的“故事”