.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
抽象问题的模型
抽象的本质是提取共性。但提取共性的范围不一定是你理解的意思。
有A，B，C三个模块为D提供服务，为了简化D的使用方式，我们提取A、B、C的共性，形成E ，E作为A，B，C对D的代理对D提供服务。
这看起来是顺理成章的。但这是静态的观点。它假设这个系统不会再改变了，但实际上我 们抽象的目的恰恰是系统还是会改变的。我们要预判这个改变是什么。
当我们考虑“提取共性”的时候，我们不一定注意到，我们是有目的的。A、B、C都可以点灯 ，我们抽取的共性是“点亮，熄灭”，但我们未来可能要考虑这个东西是不是过热了，我们 就需要抽取“过热”这个共性了，没有考虑这一点。A、B、C对于过热这个特性的理解可能就 不一样，比如A可能提供的是温度，B提供的是“对我是否过热了”，C提供的是“几级过热”， 那你如何抽象？
更何况，你基于A、B、C的这些特征抽象了，以后加入A+不符合这些特征呢？
所以，我们不基于共性来提取特征，我们基于“竞争力”来提取特征。“竞争力”才是驱动整 个系统改进的动力。
这样，我们才能抽象出正确的接口来。
但竞争力有上和下两个部分，上是用户期望。“我期望你的模块1秒钟就完成我的数据加密” ，这是期望，做到了，妥妥的竞争力。问题是大家都做不到。
这时，下的具体情况就变成了主要矛盾。A的方法可以10秒完成，B的方法1分钟，C的方法 一个小时。显然，A虽然不能满足期望，但它会在竞争中取胜。E的接口定义需要向它靠拢 。
所以高以下为基，构架是个平衡的动作。我们先用上的期望来抽象我们的接口，然后我们 用这个要求去K下的实现，摸到下的底线在哪里，基于这个底线来调整抽象，最后才会得到 合理的接口。
这就是我们不能把架构“做死”的理由。
所以架构师去K模块的设计师是个必然事件，没有这个过程，架构抽象不可能好，但他并不 预期模块设计师不会K回来。对K是架构演进的必然组成部分。