Table of Contents
- 共性可变性分析
- 需求矩阵
软件开发中最大的问题之一为：处理问题域中的变化。初次拿到软件需求，看似有一定规律，但也存在各种特殊情况。怎样发现共性，及其变化，Alan在他的书中(design patterns explained)中给出了两种方法：共性可变性分析，和需求知矩阵。
共性可变性分析
先找出概念，及它们的各种变化。 然后分析概念之间的关系，通过从大到小的顺序。背景法。如果概念1使用了概念2，则概念1是背景，应该先分析概念1。相当于先搞出框架，然后填东西，这样会更高效一些。
将概念定义为接口，而它们的变化则定义为具体实现类。
几乎所有的问题都可以这样进行分析。
比如，对于一个发布文章到博客网站上的需求：
- 能够发布html格式的文章
- markdown 格式的文章
- 能够发布到wordpress, cnblogs, blogger, chinaunix, github
- 文章中可以有图片
其中概念为： 文章， 发布器 注： 怎样寻找概念： 1. 名词。 2. 动词再个"er"，将它变为名词。 其中文章的变化为： html格式，markdown格式 发布器的变化为 wordpress发布器， cnblogs发布器， blogger发布器。
只有这两个概念。 再来看两个概念间的联系。发布器会到文章，因此我们先来分析发布器。文章可以作为发布器的一个参数。
要发布一篇文章到某个目标，先创建一个目标的发布器，再创建文章，然后将文章传给发布器。
发布器和文章还可能有一处关系： 即存在第三个概念，将二者作为参数，进行发布。这种其实跟前者只有略微差别，在实际中可不计较二者的微小差异。不要钻牛角尖。
需求矩阵
使用需求矩阵，可以更加明确地找出概念及变化，尤其是对于复杂的需求。
先在需求中找出需要处理的情况。然后对每种情况的，从需求中找出其中的概念。每拿到一个具体的条目，就找出可能表示它的通用概念，然后第一列表示概念，第二列表示第一种情况。每行表示一个概念及其变化。当处理完第一种情况后，继续处理第二种情况，同样对于每个条目，如果它的概念已经存在，则直接填在相应行，否则就扩展矩阵，添加一行用于表示这个新的概念。
最终完成后，每一行可以通过一个stratege模式处理，然后通过 abstract factory模式为每一种情况（每一列）创建处理对象。