架构师的第一步：学习两种抽象视角(Abstraction View)

[ IT史上最完整、最经典的软件框架开发技术宝典 (上百篇经典文章&eBooks) ]

ee                                                                        ee

欢迎访问 ==>高老师的博客网页

高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练

EE                                                                        EE

架构师的第一步：学习两种抽象视角(Abstraction View)

• 第一种抽象视角：架构师基于<变与不变分离>的视角，寻找<万变不离其宗>的宗，其宗(架构)的不变性带来简单性；让人们能透过掌握简单来驾驭复杂(多变)，落实了架构师的职责。

• 第二种抽象视角：架构师基于<形与内涵分离>的视角，由于不同内涵之间的<变与不变分离>已经由第一种视角所抽象了。这个视角可从内涵中抽像出共同之形，也可以(无中生有地)创造一种造形(Form)来容纳内涵(包括变与不变部分)。由于我们常常拿船运业的集装箱(Container)来比喻<造形>；而拿形形×××的货品来比喻其(集装箱)内涵(Content)。所以第二种视角，又称为<集装箱式>抽象视角。

1. 如何找到简单?  取决于人们的抽象视角(View)

   一位著名的软件专家Fred Brooks，40年前就在他的《人月神话》一书里说道：“软件的复杂是本质性的(Essential)，并非表象而已”。另外，著名软件架构师周爱民先生在他的《大道至简》一书里是说：“软件的本质是简单的”。其实这是一体的两面，分别是两个命题，软件有复杂的一面，也有简单的一面。我们能不能把这两个结合起来？但是我们为什么偏向于“大道至简”？因为我们在遇到复杂的时候总是先找简单，因为简单不会让我们害怕。

那么我们面临的挑战是：怎样找到简单呢？也就是，我们如何从复杂中得到简单？人类最擅长的手段(做法)就是抽象(Abstraction)。所谓抽象，就是从复杂中抽离出重要现象。然而，那些才是<重要>的现象呢?那决定于个人(抽象者)的视角(View)而定了。例如，你在画一只猫的时候，猫的胡须是否重要而清晰画出来呢? 往往东西方画家的抽象视角就不一样了。因之，当人们基于某一个视角而抽出<重要>现象之刻，其实也删除了一些<不重要>的现象；但是这些不重要的现象，却往往是另一视角下的<重要>现象。例如，人们从<变与不变>的视角去看猫，把善变的现象删除了，可能就将猫胡须删除了。然而，有人基于另一视角，认为胡须是猫不可或缺的(Essential)部分，没有胡须就不能称之为猫。<变与不变>只是众多视角之一而已，并不是抽象的唯一视角；所以，它不是找到简单的唯一途径。

把复杂去掉而得到简单，是一种抽象

   刚才说过了，我们大多偏向于“大道至简”？因为我们在遇到复杂的时候总是先找简单，因为简单不会让我们害怕。由于我们往往讨厌复杂多变的现象，习惯于把很多具象的东西去掉差异性、多变性的东西，这成为我们习惯性的抽象行为。这样做对不对？或是好不好呢?

或许没有对错，也没有好坏；但是我们要先找到众多具象的东西，却要找很久，团队就不敏捷(Agile)了。所以这样一个抽象的概念跟敏捷刚好冲突，所以敏捷在这种团队会很困难，因为你要想要找到简单就先要找到所有的复杂，旷日又废时。还有当你把一堆猫都抓过来你会发现它们的胡须都不一样。那就把胡须去掉，尾巴不一样就把尾巴去掉，但是没有胡须、没有尾巴的东西还能称为<猫>吗？

回归”本质(Essence)”之意

   传统上，大家认为架构师本身的职责是去寻找不变的结构，这合理吗? 想想在敏捷(Agile)里非常重视重构(Re-factory)么，重构就要靠架构师，但是传统架构师本身是想寻找不变；此时如果让他重构，他又能重构些什么呢？所以我们有必要去改变架构师的想法，让架构师自己先敏捷起来，要敏捷起来就得去寻找变化、善待变化，以及变化而产生的复杂。

   兹回归”本质(Essence)”之意。我们讲这个”Essential”字眼，称它为”本质”，又称为“道”。其中，道不变，本质不变，真理是简单的，所以我们在开发软件时，就好比建一栋房子，下面的地基不变，上面的房屋是可变的。所以架构师是建造平台(地基)的人，是要找不变的人，那么架构师又如何让系统易于重构、任团队敏捷呢？所以颇为矛盾。因为这个”Essential”字眼，在西方和在东方的含义不同，例如在牛津字典里，这个字眼的涵义是“不可或缺的”，并非”稳定不变”的。

把Essential的复杂包装起来，也是一种抽象

   那么，如果”Essential”是指不可或缺的，又怎样才能达到简单呢？只要想一想，女士们为什么要带皮包？把猫(不可或缺的)尾巴放进皮包里不就简单了么？而且你没去伤害猫。《大道至简》一书作者周爱民先生也写了另一本书：《大道至易》，这“易”就是改变(Change)的意思，其意味着软件之道是：软件无常态，需求和技术都不断变化中。

有效的抽象：让用户享受从简单中叫出复杂的满足感

   这是乔布斯对于用户体验的定义：让用户享受从简单中叫出复杂的满足感。大家都知道iPhone，在出品之前，大家都不知道它的长相，乔布斯从来不做市场调研，也不听取用户的声音，那他怎么做到使iPhone那么受欢迎？怎么做到满足高层次的用户体验？所以从简单中得到复杂的满足感，这叫做用户体验。所以，用户体验良好，意味着找到美好的抽象视角，得到完美的简单，让用户享受从简单中叫出复杂的满足感。圆满的抽象，其目标就是像这个猫一样非常满足，满足不用去向用户做调研，好好构思&抽象，就是一项简单的法则。

无损害的抽象：把Essential的复杂包装起来

   这个是刚刚说到的，传统上人们对于得到简单是怎样思考的。轮胎可因不同地形而变，方向盘可因不同司机而变，外貌颜色可因不同买主而变，这样你怎么来做抽样调查？所以传统上观察众多具像的复杂事物，但只能从一个角度去研究和抽象。这种传统的抽象是将复杂的东西去掉，留下简单，但如果你将猫的尾巴去掉，就会伤害牠，属于伤害性的抽象。

但是，如果你将猫的尾巴装进口袋，不仅能去掉复杂，还不会伤害猫。中国古代就有这个理念，孙悟空会72变，大闹天宫，唐三藏怎么处理？就是在孙悟空的头上安一个紧箍咒，念紧箍咒孙悟空就会头疼，所以唐僧还是达到用简单去控制复杂，但他没有去伤害孙悟空。

两种抽象视角

   现在，我来讲讲刚才两种思考方式的差别。

l 第1种：<变与不变>抽象视角。从一堆软件函数中抽象出“抽象函数”，也从一堆软件数据中抽象出“共同数据结构”。

l 第二种：<集装箱式>抽象视角。从具象的一堆函数和数据中抽象出“类结构”来包容具象和抽象的函数或数据。然后就把各种事物内涵(包括函数和数据)塞到“类结构”里面，这就是大家孰悉的面向对象(Object-Oriented)软件开发思维了。这种“类结构”就是一种代码造形(Form)，可扩大为EIT造形、设计模式(Pattern)和框架(Framework)。

基于第1种视角，软件的结构要稳定。此视角认为软件的平台就是地基，上面的房子就是App，所以房子要稳定才能建得好。这是众多视角之一，并没有不对，只是不够圆满而已。至于第2种视角，要把一堆函数和数据中塞进“类结构”(类造形)里，得先把复杂内涵抽离而提炼出简单造形(Form)。与其说是用类来表现复杂内容，不如说是把复杂内容塞进类里面。例如，白居易作诗，是先有了丰富(复杂)的感情，然后把感情塞进去诗的间单之“形”里，而不是以诗的简单之“形”去表现复杂的感情。

  造形(包括类、模式和框架)就像集装箱，其是与我们的皮包一样，本身没有任何意义，当你放鞋子进去，它就叫鞋子集装箱；一旦你放袜子进去，它就叫做袜子集装箱。同样地，你在类(Class)之形里面放东西，本身类是没有意义的，你放车子的属性和函数放进去类里面，它就叫车子类。

虽然集装箱本身没有内涵，但是集装箱却大大影响到所有货物的管理，还有运输等各层面。所有的造形都会产生这样的效益，它让管理体系从原来的复杂的货物变成单一的简单的组件，也就是从复杂中得到了简单，各层面的管理者又从简单中掌握复杂，它的经济效益就这样产生出来了。这也就是，为什么面向对象(Object-Oriented)只是创造一个类(Class)之形，却影响了整个软件产业界的缘由。

结语

   <集装箱式>抽象只是众多视角之一，并不是要取代传统的<变与不变>抽象视角。本文的用意在于阐述<集装箱式>的抽象视角和技术，让你的心中拥有多视角(Multiple View)的习惯，能够进行更圆满的抽象，设计出更有效的软件造形和框架，它们具备三个特性：结构简单、内涵复杂和重复组合；让人们能将猫的胡须、尾巴都装进口袋里，不仅能得到简单，又不会伤害猫；因而能获得更为圆满的抽象、更为有效的软件框架或架构了。◆