Why
在最近的设计过程中，我发现我不止一次的使用一种类似的设计方案，这种设计方案会从纷繁复杂的表象中发现(或者说理清)业务的本质，使代码变得简单，系统更容易维护。第一次运用这种技巧已经是几年前的事情了，因为最近又两次用到这个技巧，因此决定把这种技巧写下来，并给它取了一个名字: Pattern Mapping, 中文名叫 模式映射 。
先来看一个例子，我们有一个系统，它的其中一个业务是把数据从一种 源数据库(Source) 同步到另外一种 目标数据库(Target) , 而不同数据库之间进行同步的时候，为了达到最高的性能，会采用不同的同步方式，比如(这里只是为了说明问题，不代表真实实现):
- MySQL -> Spark: 采用MR
- MySQL -> Oracle: 采用DataX
- MySQL -> HBase: 采用HBaseBulkLoad
一种比较原始的做法是针对每种不同的Source -> Target组合，我们都各自编码，写着写着，你会发现有些组合的业务逻辑是类似的，比如MySQL -> Oracle, MySQL -> PostgreSQL都是用DataX同步，于是你的代码里面会出现一些if-else判断逻辑:
if ((source == MySQL && target == Oracle)
|| (source == MySQL && target == PostgreSql)) {
// balabalabala
}
...
if ((source == aaa && target == bbb)
|| (source == ccc && target == ddd)) {
// balabalabala
}
...
if ((source == eee && target == fff)
|| (source == ggg && target == hhh)) {
// balabalabala
}
...
在系统开发的初期，这种if-else逻辑不多的时候，还没有什么问题。但是当我们支持的数据源越来越多时候，你会发现这种if-else如此之多，以至于你已经没办法理清所有的业务逻辑；你要新增对于一种数据库的支持的时候，你不知道到底哪些if-else需要进行修改。因为这些Source和Target之间产生了类似笛卡尔积的关系，凡人是理不清这之前的关系的:
代码开始腐烂，人员开始流失，可能要考虑推倒重来了。
Pattern Mapping
等等，让Pattern Mapping来试试拯救你。
Pattern Mapping，或者说模式映射，是指针对一组纷繁复杂的业务，我们不是直接针对裸的原始输入进行业务规则的定义，而是从中抽象出其本质的几种Pattern, 然后把原始输入跟Pattern进行Mapping，从而构造出整个系统。
这些Pattern其实才是业务的本质，因此这样理出的Pattern的个数一般会比原始数据源的个数小一个数量级，从而降低了整个问题的复杂度。比如说上面的例子，我们其实可以抽象出几种Pattern:
| Pattern | Mapping |
|---|---|
| 可以用DataX同步的 | MySQL -> Oracle, MySQL -> Postgresql |
| 可以用BulkLoad同步的 | 任意数据库 -> HBase |
| 可以用MR同步的 | Spark -> MySQL |
这样代码就变成了:
if (isDataXCompatiable(source, target)) {
// 使用DataX同步
}
...
if (isBulkLoadCompatible(source, target)) {
// 使用BulkLoad进行同步
}
...
if (isMRCompatible(source, target)) {
// 使用MR进行同步
}
你会发现这个代码里面没有任何地方对具体的 source, target 的类型进行判断，我们编程针对的是业务的本质，而不是裸的业务输入，从而减少了这种if-else的个数，在原来的笛卡尔积问题中间加入了中间的Pattern, 降低了问题的复杂度:
它把原来的
M x N的问题 变成了M + X + N的问题。
结论
Pattern Mapping适用的场景是: 业务逻辑的输入因子有很多可能的值，这些因子之间可能会相互作用，但是不同因子之间是有一些共通的Pattern。使用Pattern Mapping使得我们可以抓住业务的本质，使得我们面向业务的本质编程(而不是裸的业务输入), 降低了业务的复杂性，提高了代码的可维护性。
