抽象問題的模型

抽象的本質是提取共性。但提取共性的範圍不一定是你理解的意思。

有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是架構演進的必然組成部分。