观察者是不是有自己感兴趣的事件？是被动地让观察者获得通知，还是让观察者来主动获取？如果观察者和目标之间有更复杂的关系怎么办？是不是要把历史的通知都记录下来？ 你可以任意展开想象。很有趣，对吗？如果你拥有丰富的生活阅历，也许会想到更多有价值的事情。不过请记住，所有想象的前提，都是基于最初提到的隐喻。 

隐喻使你的想象变得集中而有条理。对于有经验的小程序二次开发人员来说，编程，只是用一种语言表达想象的过程，基本上没有任何难度。这就是隐喻的价值。软件架构中的隐喻与设计模式中的隐喻没有什么不同。如果一定要说出一些不同的话，那就是，在使用隐喻来构架软件系统的过程中（准确地说，在想象的过程中），还需要考虑很多约束条件。这些约束条件的判断和取舍，来自软件架构师的经验。这个过程几乎无法用逻辑思维的语言来描述，这有点像指挥一次战役：战场上的形势瞬息万变，没有哪一本教科书可以告诉你永远正确的行动计划。

不是所有的隐喻都直接有助于小程序二次开发，只有越简单的隐喻才越有价值。在软件开发中，抽象的特征，是简化对事物的主观认识，隐喻的目标是抽象，因此，隐喻也肩负着简化认识的使命。例如，在观察者模式中，既不必把观察的地点转移到黑洞附近，也不必对观察者是否高度近视耿耿于怀（如果一定要解决这些问题，应该在不破坏简单隐喻的前提下，以更灵活的方式对这类特殊情况进行抽象）。所以说，抽象能力决定了隐喻的好坏。隐喻的另一个重要作用，是便于团队成员的交流。以大连考试软件开发设计模式为例，观察者的隐喻可以使Observer模式被大众快速接受并理解。我想象不出，如果换一种方式，知识的传递还会这么有效吗？

软件架构中的隐喻也具有同样的功能。在一种简单隐喻之下，团队成员对正在开发的产品有一种共同的想象，这会大大激发团队创造的化学反应。场景故事点评：孔如之把业务领域的故事与技术实现完全对应起来了。他认为，在架构中，要有一个和需求故事对应的层。这个层完全由接口组成。它代表了故事的结构和线索。这将使程序的结构也能像故事一样层次清晰。这种做法，本质上是一种隐喻式开发，具有丰富的想象力和创造力。隐喻和想象，在小程序二次开发中占有重要的地位。可是，如何进行想象才能产生出好的隐喻呢？除了前文中提到的简单原则和约束原则之外，还需要具备哪些条件，才可以开始为了设计软件而展开想象呢？