在上述对对象系统的讨论中，我们首先考察的是剥离掉继承性之后的对象——亦即一组性质，或称之为一个复合的数据(或结构体)。对于这样的数据，GoF模式从“数据间关系”的角度上，为每个子系统(一组数据)定义了两类可能的产出，其一①GoF对元类的叙述是没有的，但这不妨碍用GoF模式在语言去中实现元类继承。

② Adapter for Class、Interpreter和Template Method的“范围”为“类”,表明它们可以是类上的行为，而并非是指它们“产生类”。

为结构型，即一组有关系的数据；其二为行为型，即一组有关系的逻辑。上述所谓产出的方式，既可以是指执行该子系统(而得到运算结果),也可以是指对该子系统重新结构(而最终达到某种外观表现)。因此，GoF模式本质上是说明：s(f)+s(d)即"结构(逻辑+数据)"这样的基本模型作用于数据间关系之后的产出。

这样看来，尽管我们讨论GoF模式时是面向(或基于)对象系统的，但其中的绝大多数模式与“对象”并没有必然关系。同样，即使我们将这些模式的应用泛化到纯粹的“数据的获取、展示与调度”这一层面，也仍然只是它——作为思维方式——的一种应用。

我们可以(也是可选地)将这一思维方式提升到系统层面，那么我们会发现，GoF模式也可以是一种系统组织方式。这种情况下，系统中的工件并非是数据，而是各种应用与应用间的消息，前者可以理解为s(f),后者则可以理解为s(d)。

以此为起点，我们事实上是在将GoF思想延伸到系统设计的各个领域。例如著名的系统设计模式MVC以及常用的插件框架，就可以视作几种GoF模式应用于某种、某类数据以及某个领域的结果。yipindushu.com

①参考《程序员修炼之道——从小工到专家》之“29它只是视图”中的“超越GUI”一节。

【3黑三点首的5】

【(1)彩些源装1本很】

程序与算数之间的关系，早就有人描述过了。尼古拉斯·沃斯(Niklaus Wirth)说“算法+数据结构=程序”,并把这一论断用作书名，终成名句。其实这与《算数书》这一书名是同一个意思。古人与今人在类似事物上的、最接近本质的理解，其实是一样的。

从形式上说，特定计算机系统相关的“程序”是略有不同的——它们是为一个可计算系统编制特定序列的编码。这些编码的本意是可以控制机器的指令，只是为了让程序员和计算系统可以存在一致的理解，进而便于将程序员思维映射为计算系统的行为，我们才让这些编码变成了可供人们阅读的文本。

然而无论从算数的必要性，还是从计算机系统的必要性来看，我们都无法解释某些代码文本出现的原因，例如Module。因为类似这样的一些抽象概念，既非可参与计算的单元，也非计算机系统可以理解的指令。

对这一问题的反思揭示了应用开发思想的出处。

所谓应用开发，并不首要关注对现实系统的抽象或基于该抽象的可计算性的讨论，而是面向“一个应用”整体的系统化思考。因而其思想的核心，便在于如何更加有效地解构再组织这一系统。最终，我们将这一系统化的产出称为软件，或更进一步地与它的市场行为联系起来，称之为软件产品。

任何一个所谓的“应用",首先必然是一个或一组“程序”。这意味着它总是能用此前讨论的技术来完成“程序的功能”,例如，我们总是可以将一个现实的问题抽象为对象系统，并面向该对象系统来实现程序逻辑。这一过程在我们此前的讨论中已经一再复述。

但是一旦我们开始讨论应用本身的问题，则必然涉及它的两种内在驱动力量：□所面向的是泛计算领域中的某个或某一类用户；□所处理的是某一个独立领域中的单一问题或特定范围的问题集。

由于这里的“用户”是指非专业的计算机操作者，因此他们对程序的使用方法和维护方法决定了两类与“现实的问题抽象”相距甚远的需求：□非功能性需求；口非当前需求。

这些，就是应用开发所面临的全部问题的背景与焦点。