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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

熟悉一点html css的人知道:

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

类似java: 

class P implements A ,B{
...
}

函数式编程可通过函数方程将多个类型组合在一起使用,如同方程式:

x(A) + y(B)

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

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

以CSS为例:

.A B{
font-size:16px
}

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

   
这里显示16px文本

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

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

banq注:

  • ​​​​​​​组合:将上下文的类型抽象,将上下文的类型形式化;
  • 继承:对上下文直接绑定,特别是在无法认清上下文的类型是什么情况下,继承可以帮助你快速解决问题。

https://www.jdon.com/69903.html

你可能感兴趣的:(javascript,reactjs)