模式

什么是模式

Each pattern is a three-part rule, which expresses a relation
between a certain context, a problem, and a solution.
每一个模式是一个三方规则，表现了一个特定上下文、一个问题和一个解决这三者之间的关系。
模式是从一个具体问题中抽象出来的“问题-解决”。

例子
一个人机交互的产品，界面经常要变，而且需要匹配不同的系统，所以设计为：

把界面分为view和controller两个模块，view组件用来显示信息给用户，并接收来自用户输入；controller接收输入，通常是鼠标键盘。
模式不是人工随意创建的，而是基于专家们的经验，我们可以使用这些模式而不必具有这些经验。图中讲述的model-view-controller模式是经典的小型对话系统架构，比如MacApp。
模式通常定义一些类（class）、实例（instance）或者组件（component），以及他们之间的责任、关系和交互。
他避免了用长篇大论来描述一个问题的解决方法。有的时候你用一个模式名就能解释，比如上述的model-view-controller。使用现有的模式可以节约时间。
模式只是提供了一个框架（scheme），而不是所有的细节。
总之：
A pattern for software architecture describes a particular recurring design
problem that arises in specific design contexts, and presents a
well-proven generic scheme for its solution. The solution scheme is
specified by describing its constituent components, their responsibilities
and relationships, and the ways in which they collaborate.
模式是描述在特定设计上下文中的特定的重复的设计问题的软件架构，它提供了这个问题的被证明是好用的解决框架。这个框架描述了框架组件之间的关系与协作。

模式的构成

前一节我们提到的概念context，problem，solution是所有模式的共性。
context：指的是问题在什么状态条件下出现。它有可能很普通，比如“开发一个人机交互界面”，也可能是特定的，比如“应用model-view-controller变体机制”。通常我们很难准确定义出context，所以可以枚举所有的问题可能出现的条件和场景。
problem：当然是只要解决的问题，有个重点是需要列出他的限定（强制 force），比如上述模式中，他的限定是必须易于改变。
solution：答案指的是怎么解决问题，也可以说怎么平衡这些限定。答案包括两部分，一部分是静态部分，比如model-view-controller可以解释为：把 应用分为三部分：处理，输入和输出。一部分是动态部分，描述静态部分的行为，比如：controller收到input并把它转为服务请求，转给model或view。当然，答案并不一定要解决所有的限制，尤其是这些限制有时是互相矛盾的。

模式之间的关系

模式可以一起使用。
例子：透明的端到端进程间通信。假设你必须要开发一个分布式应用，需要高性能端到端进程间通信。以下的限制必须满足：

• 进程间通信必须高效。长时间等待寻找服务器位置是不允许的。
• 独立于某种特定的通信机制，比如通信机制改变不会影响client/server.
• client不知道server的位置和名字。看起来他们像在同一个进程里通信。
  解决方法：
  
  使用forwarder-receiver和proxy两种模式。forwarder-receiver解决前两个问题，proxy解决第三个问题。

Note必须给模式取一个合适的名字，因为名字就解释了模式本身。而且，来自世界各地的专家基本已经cover了好的模式，所以如果可以，先使用已有的。（嗯，我也不想创造新的）
为了开拓模式最大的作用，将在第5章介绍科学的使用方法。