抽象两种方法：上下文与类型

“抽象”的中文意思是“抽出象形”。奥妙就在于实现手段有很多，也是创新所在，这里比较三种手段：

首先是中文字面意思上的“抽象”：抽出象形，中国文化谓之为神，例如中国水墨国画，还有古诗词：“窗前明月光疑是地上霜”，明月光和地上霜是两个有实在内容的实体，李白把它们类比在一起，起到举一反三作用，这两件事物的共同点，也就是那种白颜色的神韵跃然纸上。这是中文抽象的最高境界之一。

类比比喻形象化等思维方式在这种抽象中起到关键作用。

如果我们想知道：李白为何能写出如此美妙诗歌？
这个疑问会让我们好奇李白当时写这首诗的上下文环境。

1、上下文
在研究上下文时，显然我们不是在研究这首诗的内容，抛开具体内容寻找其诞生的前因后果。
至少开启了形式思考之门，这种形式是完全与内容无关，无关于月光和地上霜等具体内容。
开启形式化之路首先需要选择方向，形式化是一条新的道路，方向是道路的战略选择，关键创新力也会在这里出现。

单就案例”李白的窗前明月光“，我们可以抽离出多少或什么样的无关内容的形式呢？
其实，人类下意识都是基于内容推理的，因此，无论谁都很难摆脱内容的干扰，最多是围绕内容周边实现形式化抽象。

假设一个上下文场景，注意这只是一种假设，这种假设可能是错的：
如果我们还有李白的第二首诗，甚至很多诗歌，如果我们都抛开每首诗的内容，致力于研究李白每首诗的上下文，那么是不是可以得出一种形式类型：李白诗？

2、类型化
类型化是形式化以后最自然的一种抽象方法。

我们把李白诗放在windows的一个文件目录，称为目录或context，以后是不会把白居易的诗放到这个目录下。

由此我们有了一个class类：LiBai
下一步是如何使用这个类型，形式是为了内容或功能服务，变成类型的好处是规范形式内的功能，其次能够快速定位到内容。寻找李白的诗只要找到李白的目录即可。

但是，如果有人想直接查询窗前明月光，那么你之前的类型分类假设就无效了，不知道李白的人只能遍历所有目录。这与说明类型设计也是一种自以为是的假设，这种假设是有前提的，如果使用场景不符合这个前提条件，你的类型形式化设计无效。

关键是我们形式化思考的方向选择上，之前分类是基于李白分类，可能因为我们有白居易等人诗歌，也可以从题材方向归类，例如分类为月光类诗歌、太阳类诗歌等。

所以，诡异之处在于分类依据是什么？分类依据取决于整个数据的上下文，可能仁者见仁智者见智，这时人工智能比较擅长从多方面分类了。

抽象后的使用
假设你的类型设计正确，下一步会遇到是组合使用还是继承使用的问题。

假设class有A和B两种，这里不以李白和白居易作为类名，防止被内容干扰，当然如果理解类型费力，还是可以用这两个人名字作为类型名称。

1、组合使用：
组合使用是将两种以上类型组装在一起使用。

熟悉一点html css的人知道：
<p class="A B">

表示这个段落p使用A和B的组合显示风格。

类似java：
class P implements A ,B{
...
}

函数式编程可通过函数方程将多个类型组合在一起使用，如同方程式：
x(A) + y(B)

2. 继承使用
如果类型抽象得正确，组合使用无疑是优先选择，但是问题在于：类型可能抽象错误了。

在这个时候，如果我们稍微更靠近内容，更靠近实际情况，更细化一下，通用性放弃点，与内容上下文绑定得更紧密一点，这时的抽象也是管用的，至少对于特定场景有用。

以CSS为例：
.A B{
font-size:16px
}

这时的B是限定在A这个类型下：

以Java为例，使用extends等关键字。

继承者B被限定在被继承者A的上下文中，在内容或功能上两者绑定在一起。

banq注：