架构师“集装箱式”抽象视角的演练

返回本文：智能＆大数据时代， 架构师思维的十个学习步骤



ee ee欢迎访问 ==>高老师的博客网页高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练
EE EE架构师“集装箱式”抽象视角的演练
內容：
第一篇：复习基本概念
第二篇：实践与演练

第一篇：复习基本概念AA B1. 学习两种抽象视角(Abstraction View)第一种抽象视角：架构师基于<变与不变分离>的视角，寻找<万变不离其宗>的宗，其宗(架构)的不变性带来简单性；让人们能透过掌握简单来驾驭复杂(多变)，落实了架构师的职责。
第二种抽象视角：架构师基于<形与内涵分离>的视角，由于不同内涵之间的<变与不变分离>已经由第一种视角所抽象了。这个视角可从内涵中抽像出共同之形，也可以(无中生有地)创造一种造形(Form)来容纳内涵(包括变与不变部分)。由于我们常常拿船运业的集装箱(Container)来比喻<造形>；而拿形形色色的货品来比喻其(集装箱)内涵(Content)。所以第二种视角，又称为<集装箱式>抽象视角。

1.1 如何找到简单? 取决于人们的抽象视角(View) 一位著名的软件专家Fred Brooks，40年前就在他的《人月神话》一书里说道：“软件的复杂是本质性的(Essential)，并非表象而已”。另外，著名软件架构师周爱民先生在他的《大道至简》一书里是说：“软件的本质是简单的”。其实这是一体的两面，分别是两个命题，软件有复杂的一面，也有简单的一面。我们能不能把这两个结合起来？但是我们为什么偏向于“大道至简”？因为我们在遇到复杂的时候总是先找简单，因为简单不会让我们害怕。那么我们面临的挑战是：怎样找到简单呢？也就是，我们如何从复杂中得到简单？人类最擅长的手段(做法)就是抽象(Abstraction)。所谓抽象，就是从复杂中抽离出重要现象。然而，那些才是<重要>的现象呢?那决定于个人(抽象者)的视角(View)而定了。例如，你在画一只猫的时候，猫的胡须是否重要而清晰画出来呢? 往往东西方画家的抽象视角就不一样了。因之，当人们基于某一个视角而抽出<重要>现象之刻，其实也删除了一些<不重要>的现象；但是这些不重要的现象，却往往是另一视角下的<重要>现象。例如，人们从<变与不变>的视角去看猫，把善变的现象删除了，可能就将猫胡须删除了。然而，有人基于另一视角，认为胡须是猫不可或缺的(Essential)部分，没有胡须就不能称之为猫。<变与不变>只是众多视角之一而已，并不是抽象的唯一视角；所以，它不是找到简单的唯一途径。
1.2 把复杂去掉而得到简单，是一种抽象 刚才说过了，我们大多偏向于“大道至简”？因为我们在遇到复杂的时候总是先找简单，因为简单不会让我们害怕。由于我们往往讨厌复杂多变的现象，习惯于把很多具象的东西去掉差异性、多变性的东西，这成为我们习惯性的抽象行为。这样做对不对？或是好不好呢?或许没有对错，也没有好坏；但是我们要先找到众多具象的东西，却要找很久，团队就不敏捷(Agile)了。所以这样一个抽象的概念跟敏捷刚好冲突，所以敏捷在这种团队会很困难，因为你要想要找到简单就先要找到所有的复杂，旷日又废时。还有当你把一堆猫都抓过来你会发现它们的胡须都不一样。那就把胡须去掉，尾巴不一样就把尾巴去掉，但是没有胡须、没有尾巴的东西还能称为<猫>吗？
1.3 回归”本质(Essence)”之意 传统上，大家认为架构师本身的职责是去寻找不变的结构，这合理吗? 想想在敏捷(Agile)里非常重视重构(Re-factory)么，重构就要靠架构师，但是传统架构师本身是想寻找不变；此时如果让他重构，他又能重构些什么呢？所以我们有必要去改变架构师的想法，让架构师自己先敏捷起来，要敏捷起来就得去寻找变化、善待变化，以及变化而产生的复杂。 兹回归”本质(Essence)”之意。我们讲这个”Essential”字眼，称它为”本质”，又称为“道”。其中，道不变，本质不变，真理是简单的，所以我们在开发软件时，就好比建一栋房子，下面的地基不变，上面的房屋是可变的。所以架构师是建造平台(地基)的人，是要找不变的人，那么架构师又如何让系统易于重构、任团队敏捷呢？所以颇为矛盾。因为这个”Essential”字眼，在西方和在东方的含义不同，例如在牛津字典里，这个字眼的涵义是“不可或缺的”，并非”稳定不变”的。
1.4 把Essential的复杂包装起来，也是一种抽象 那么，如果”Essential”是指不可或缺的，又怎样才能达到简单呢？只要想一想，女士们为什么要带皮包？把猫(不可或缺的)尾巴放进皮包里不就简单了么？而且你没去伤害猫。《大道至简》一书作者周爱民先生也写了另一本书：《大道至易》，这“易”就是改变(Change)的意思，其意味着软件之道是：软件无常态，需求和技术都不断变化中。
1.5 有效的抽象：让用户享受从简单中叫出复杂的满足感 这是乔布斯对于用户体验的定义：让用户享受从简单中叫出复杂的满足感。大家都知道iPhone，在出品之前，大家都不知道它的长相，乔布斯从来不做市场调研，也不听取用户的声音，那他怎么做到使iPhone那么受欢迎？怎么做到满足高层次的用户体验？所以从简单中得到复杂的满足感，这叫做用户体验。所以，用户体验良好，意味着找到美好的抽象视角，得到完美的简单，让用户享受从简单中叫出复杂的满足感。圆满的抽象，其目标就是像这个猫一样非常满足，满足不用去向用户做调研，好好构思&抽象，就是一项简单的法则。
1.6 无损害的抽象：把Essential的复杂包装起来 这个是刚刚说到的，传统上人们对于得到简单是怎样思考的。轮胎可因不同地形而变，方向盘可因不同司机而变，外貌颜色可因不同买主而变，这样你怎么来做抽样调查？所以传统上观察众多具像的复杂事物，但只能从一个角度去研究和抽象。这种传统的抽象是将复杂的东西去掉，留下简单，但如果你将猫的尾巴去掉，就会伤害牠，属于伤害性的抽象。但是，如果你将猫的尾巴装进口袋，不仅能去掉复杂，还不会伤害猫。中国古代就有这个理念，孙悟空会72变，大闹天宫，唐三藏怎么处理？就是在孙悟空的头上安一个紧箍咒，念紧箍咒孙悟空就会头疼，所以唐僧还是达到用简单去控制复杂，但他没有去伤害孙悟空。
1.7 两种抽象视角 现在，我来讲讲刚才两种思考方式的差别。l 第1种：<变与不变>抽象视角。从一堆软件函数中抽象出“抽象函数”，也从一堆软件数据中抽象出“共同数据结构”。l 第二种：<集装箱式>抽象视角。从具象的一堆函数和数据中抽象出“类结构”来包容具象和抽象的函数或数据。然后就把各种事物内涵(包括函数和数据)塞到“类结构”里面，这就是大家孰悉的面向对象(Object-Oriented)软件开发思维了。这种“类结构”就是一种代码造形(Form)，可扩大为EIT造形、设计模式(Pattern)和框架(Framework)。
基于第1种视角，软件的结构要稳定。此视角认为软件的平台就是地基，上面的房子就是App，所以房子要稳定才能建得好。这是众多视角之一，并没有不对，只是不够圆满而已。至于第2种视角，要把一堆函数和数据中塞进“类结构”(类造形)里，得先把复杂内涵抽离而提炼出简单造形(Form)。与其说是用类来表现复杂内容，不如说是把复杂内容塞进类里面。例如，白居易作诗，是先有了丰富(复杂)的感情，然后把感情塞进去诗的间单之“形”里，而不是以诗的简单之“形”去表现复杂的感情。 造形(包括类、模式和框架)就像集装箱，其是与我们的皮包一样，本身没有任何意义，当你放鞋子进去，它就叫鞋子集装箱；一旦你放袜子进去，它就叫做袜子集装箱。同样地，你在类(Class)之形里面放东西，本身类是没有意义的，你放车子的属性和函数放进去类里面，它就叫车子类。虽然集装箱本身没有内涵，但是集装箱却大大影响到所有货物的管理，还有运输等各层面。所有的造形都会产生这样的效益，它让管理体系从原来的复杂的货物变成单一的简单的组件，也就是从复杂中得到了简单，各层面的管理者又从简单中掌握复杂，它的经济效益就这样产生出来了。这也就是，为什么面向对象(Object-Oriented)只是创造一个类(Class)之形，却影响了整个软件产业界的缘由。
1.8 结语 <集装箱式>抽象只是众多视角之一，并不是要取代传统的<变与不变>抽象视角。本文的用意在于阐述<集装箱式>的抽象视角和技术，让你的心中拥有多视角(Multiple View)的习惯，能够进行更圆满的抽象，设计出更有效的软件造形和框架，它们具备三个特性：结构简单、内涵复杂和重复组合；让人们能将猫的胡须、尾巴都装进口袋里，不仅能得到简单，又不会伤害猫；因而能获得更为圆满的抽象、更为有效的软件框架或架构了。◆

第二篇：实践与演练AA B
Step-1.理解架构师的任务，就是组合创新：带领团队将一群不会飞的零件，设计有效的架构和接口，将它们组合起来，而且会飞上天空。
Step-2. 领悟”抽象”的目的：从复杂中找到简单的组合形式(Form)；然后反过来，从简单中掌握复杂，不畏惧复杂，勇于改变和行动去追寻组合创新，实现美好的愿景(Vision)。人们在遇到复杂的时候总是透过抽象来找简单，因为简单让我们不害怕。Step-3. 抽象角度(视角)可能人人不同，其抽象途径不同，抽象结果(简单形式)也不同。然后，组合途径、创新策略和商业效果都因而不相同。Step-4.视角(View)不是本体，其本身并没有对或错；但是坚持单一视角，并认为是真理，可能就错了。有效架构师必须兼具多重视角(Multiple-view)。Step-5. 认识两种常见的抽象视角：● <变与不变分离>的视角，又称为传统的抽象视角。● <内涵与形式分离>的视角，又称为“集装箱式”抽象视角。Step-6. 演练抽象视角—以猫为例● 基于<变与不变分离>视角，分析一群猫的複雜行为和结构，观察其差异性，看到了，猫的胡须和尾巴是善变的，而猫的身体比较稳定不变；然后抽象出不变的部分，而从复杂(多变)得到了简单；这个简单形式只有身体，而没有胡须和尾巴。● 基于<内涵与形式分离>视角，分析一群猫的行为和结构，领悟其不可或缺(Essential)性，找出基本要素和关系，设计出简单造形(形式)，就从复杂(多变)得到了简单。然后，从简单造形组合出较大造形，再组合出更大造形，就如同人体的DNA螺旋状组合结构一样。于是，猫的不可或缺性(包括善变的行为和结构)都成为<内涵>，被容纳于<造形>之内。从简单造形出发，组合出复杂造形，容纳复杂多变的不可或缺性，达到掌控复杂的目的。Step-7.分辨”本质(Essence)”之意。这个”Essential”字眼，在西方和在东方的含义不同。东方通常称它为”本质”，又称为“道”。其中，道是万变不离其宗的<宗>，由于不变所以简单，于是基于简单的宗，来掌握复杂多变，这偏向于<变与不变分离>的抽象视角。而在西方的牛津字典里，这个字眼的涵义是“不可或缺的”，并非”稳定不变”的。Step-8. 在西方的牛津字典里，这个字眼的涵义是“不可或缺的”，并非”稳定不变”的；其偏于<内涵与形式分离>的抽象视角。那么，如果”Essential”是指不可或缺的，又怎样才能找到简单呢？只要想一想，女士们为什么要携带皮包呢？因为要把口红、镜子、面纸等形形色色的化妆品，不可或缺的一一装入皮包里，然后提着简单的皮包(外形)，就掌握了复杂的化妆品(内涵)。
Step-9. 理解软件专家Fred Brooks在40年前首先提出软件架构的概念，他在其《人月神话》一书里主张：软件设计要有”概念一致性”(Conceptual Integrity)。他偏于<内涵与形式分离>的抽象视角，他认知到：“软件的复杂是本质性的，并非表象而已”(The complexity of softwareis an essential property, not an accidental one.)。为了包容这些不可或缺的复杂多变，他主张透过某种形式来促进设计概念的一致性；这种形式就是架构。他说到：”概念一致性是系统设计关键要素。请一位架构师来设计(一种形式)，是落实概念一致性的重要步骤”(Conceptual Integrity is the most important consideration in system design. … Having a system architect is the most important single step toward conceptual integrity.)架构提供简单的形式，容纳不可或缺的复杂(多变)内涵；因而人们能透过简单来掌握复杂。[歡迎光臨高煥堂的博客首頁：http://www.cnblogs.com/myEIT/ ]。

Step-10.<变与不变分离>抽象视角的实例演练
从一堆软件函数(Function)中抽象出 "抽象函数“。也从一堆软件数据(Data)中抽象出 "共同数据结构"。如下图所示：



例如，从下述代码中，抽像出共同的部分：




首先把相同的数据项抽象出来，如下：

private String name;
接着，把相同的函数抽象出来，如下：
String name; public void SetName( String na ){name = na; }
最后，将名称相同，但内容不同之函数名称抽象出来：
private String name; public void SetName(String na){name = na; } public abstract void Display();
其中，只抽象出Display() 名称，而内容从缺。再如：




数据项的型态并不相同，找到了相异点：





这导致函数的内容也不一样：




此时，就可定义一个新的GetData()新函数来将相异点包装起来：




于是，Print()函数变成为相同点了，就可以抽象出来了；然后也把GetData()名称也抽象出来，得到简单不变(相同)的部分：




之后，就能对这个不变部分加以扩充，把善变部分组合回来，如下图：





以上演练的就是典型的<变与不变分离>的抽样视角。
Step-11.<内涵与形式分离>抽象视角的实例演练(一)：类造形
从一堆函数和一堆数据之中，抽象或设计出 "类(Class)结构" 来包容这些函数和数据。如下图所示：





所以创造“形”出来就把各种事物想成“类”，实际是函数和数据的内涵塞到“类”里面，变成面向对象(Object-Oriented)。我们就称之“类(Class)造形”。





虽然这个“Class造形”只含有两项元素，但其威力很大，能容纳各项不可或缺的复杂。




例如，将枫叶的不可或缺特性(包括变与不变的部分)，置放到类造形里，就得到”枫叶类”了。




再如，将鹦鹉的不可或缺特性(包括变与不变的部分)，置放到类造形里，就得到”鹦鹉类”了。




Step-12.<内涵与形式分离>抽象视角的实例演练(二)：EIT造形
这种抽象视角是把一堆函数和数据中塞进类造形里，就如同女士们想把形形色色化妆品放入皮包里一样。此时，得先把复杂内涵抽离而设计出一致的简单造形(Form)—如皮包。然后才把复杂内涵放进去(一致的)共同造形里。例如，白居易作诗，是先有了丰富(复杂)的感情内涵，然后把感情塞进去唐诗的简单造形里。唐诗七言绝句，一首诗四个句子，每一个句子七个字，两项韵律(“平平仄仄平平仄，仄仄平平仄仄平”)，这是唐诗的简单造形，却能容纳多样化的复杂情感(内涵)。在软件开发中，大家最熟悉的代码层级的基本造形有二： ● 1970年代的函数(Function)造形； ● 1980年代的类(Class)造形。
自从1996年Java问世之后，接口(Interface)成为Java语言的关键词(KeyWord)。于是，<接口>的位阶已经提升了，其与<类>是同位阶了，而不再隐藏于类造形里。这意味着，我们可以设计一个更大的代码造形来包容类和接口两种元素。为了凸显接口角色，就得考虑两项特性： ● 为了清楚地定义一个接口(主角)，需要两个类来当配角。 ● 此外，接口以能实现为类(造形)。

于是，高焕堂老师将3个<类造形>组合起来，成为一个更大的造形；就像生物DNA的螺旋结构，组合如下图：



在上图里，为于中间的类就是接口实现类。高老师将其命名为EIT造形：



EIT造形也不难理解，它只是对类造形加以扩大；也就是以类为基础(保留了类的各项功能)，将3个类结合在一起，各扮演不同角色；让开发者拥有更大的视野，具有更好的整体观。以软件产业的UML标准图示来表达EIT造形如下：




基于这个EIT造形，就能将复杂内涵装进去EIT造形里了。




欲将内纳装进去造形里，可以将内涵细分为两大类：




兹举例说明之。范例之一：




范例之二：



Step-12. 从简单造形，组合出大造形，容纳更复杂的内涵：EIT造形的组合
以上举例都是单个EIT造形的运用。在实务应用上，常常需要将多个EIT造形组合起来，能发挥更大的加乘效益。例如，在智能城式领域里，智能家庭与交通车联网两大业务区块的信息系统之间，需要在通信机制和协议上取得共识或标准化。






在这个系统架构里，包含了3项内涵，其中之一是：




另外两项内涵是：




此时，架构师可以将两个EIT造形组合起来，包容这3项内涵：




于是，利用两个<E>的联合来包容通信协议内涵；如下图：




然后，利用两个<T>分别包容<智慧家庭>内涵和包容<交通车联网>内涵，如下图：




Step-13. 从EIT组合出更大造形：模式(Pattern)
举世公认的天才达芬奇(DaVinci)说：”简单是复杂的终极形式”(Simplicityis the ultimate form of sophistication)。在自然界里，只有一种原子造形，例如：氢(内涵)+原子(造形)= 氢原子。它们会依循某种规律而组合成较大的结构，如下图所示：





在软件上，造形(Form)属于原子层级；而模式(Pattern)则属于分子层级。




例如，GoF设计模式里的工厂模式(Factory Pattern)就是由两个EIT造形所组成的，如下图：




Step-13. 从EIT组合出更大造形：框架(Framewrok)
苹果公司乔布斯(Jobs)说：”创造无非就是把事物联结起来，…即若是非凡的创意通常也不过是对已有事物进行的新组合而已。”基于上述的造形和设计模式，我们可以继续组合出更大的软件架构形式，例如框架(Framework)。兹举个Android框架里的Content Provider框架为例说明之。App去存取数据库的基本结构如下：




针对两项功能：查询数据和浏览查询结果。各利用一个EIT造形来包容两种内涵：App和Database引擎。如下图：






在Android框架里，其实际代码结构如下图：




~ End ~
AA DD

欢迎试听：高老师的"教父级"在线课程<<Android从程序员到架构师之路>> (包括上层App、中层JNI&系统服务、和底层HAL驱动架构设计)WW