IT架构设计_隽语集(EIT设计模式

前言：基于parts(行人与汽车)和whole(社会)的需要的平衡之目标，架构师就设计出<红绿灯和班马线>，其规范parts之间的接口(interface)，进而细腻订定两者的互动规则(rule) ，如车站、月台、先上后下、排队上车等。上述的接口和互动规范就是架构师的核心职责，在交通系统如此，在软件、硬件系统也是如此。

架构师思维演练的第一要素是时间：从未来回顾现在。第二要素是空间：专注于领悟The needs of the whole 与 The needs of the parts。例如，街道上十字路口，其攸关的whole 和parts各为何? 其needs又为何呢? whole(如社会)和各parts(如汽车和行人)都是<实>个体，各有需求，常常互相冲突和摩擦。如何让化解冲突和摩擦，架构师要设计<虚的虚>结构(Structure)来规范协调。然而虚结构没有行动能力，架构师就创造(无中生有)一些<虚的实>个体来执行协调任务。

本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。由于软件的本质是复杂(多变)的，不能纯然去追求本质；于是，A段(软件)架构师必须先领悟其复杂本质，设计出简单之形(架构)，让人们(如软件开发、营销团队)能从简单中掌握复杂的本质。

欢迎访问 =>高老师的ADT技术论坛

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

ee ee

<<看上一集-------看下一集>>

[#701]#先进架构设计# 在架构设计上，架构师心中有三个元素：愿景(Vision)、需求(Requirement)和架构(Architecture)。那么在你心中，这三个元素之间的关系为何? 如何互动呢? 唯有简单的关系、有效的互动，才能获得有效的架构，才是一位有效的架构师。更多新思维：http://t.cn/8FbhmdD

[#702]APP开发教学都是教开发者写应用子类(subclass)去继承Android框架里的基类如Activity、Service等。所以一般人所指的APP产业并不包括Activity、Service等框架开发部分。但是应用子类(APP开发者撰写的)和框架基类(Google撰写的)组合起来才形成可以被下载执行的APK。更多新思维：http://t.cn/8FbhmdD

[#703]在汽车业里，从来无人会奢望一部汽车是全能的；既能在沙滩、街道上跑，又能在高山雪地里跑。然而在云产业、互联网、电信业里，有许多人迷信于神话中，期盼软件APP是全能的；能在众多硬件、平台上跑。EIT造形让人人从神话世界回归到产业的实境中，让神话梦想变为事实；或许你也会说我自己正在说神话。

[#704]APP是基于框架API而开发的，受制于框架拥有者，APP是一位国民，属于该王国的。如果连APP幕后(即APK里面)的框架API都是我们自己所拥有，等于我们是有了一群国民的王国。如果再拥有硬件产业支撑，就是强国了。

[#705] @让您成为杰出架构师 软硬结合产品的商业模式；例如，基于<减法思维>的规划。甚么是减法呢? 兹做个比喻，一只茶壶有一个手把；那么，请问：1)增添一个新手把; 2)把原来的手把删除；你觉得何者较容易呢? 答案是：后者极为困难；do you know why?

[#706]假装刺猬的猪:个人愚见，做好框架，同时将框架与硬件整合只是增强你在这个产业里的主导权。不追求主导权当然没必要花大力气去整合。视乎在整个产业中给自己的定位如何。

[#707]@让您成为杰出架构师#先进架构设计思维# 文化输出常常是输出造形，而不是内涵。例如，唐朝中国输出建筑造形到日本、韩国；近代西洋人输入<行政、立法、司法>三权分立的造形到东方；就是蒋梦麟所说的<西潮>。更多新思维：http://t.cn/8FbhmdD

[#708]<<架构师思维练习>> "合"的角色。华人写文章思维架构是：起承(正)-->转(反)-->合。洋人写文章是：合中有合，合引导正与反，合的结论先说，主题句(main sentence)是其合的呈现。华人的合呈现共通性、所以喜欢谈本质；洋人的合呈现独特性，喜欢说i am very special。

[#709]@让您成为杰出架构师 #架构师思维练习# 华人架构设计主要思维元素是：<分>析与<抽>象；所以常认为架构就是要有通用性。洋人主要元素是组<合>，次要元素才是<分>和<抽>；所以常认为架构要创造与众不同的独特性。更多新思维：http://t.cn/8FbhmdD

[#710]造形与经济效益。我拿唐诗与EIT框架的造形的相比来凸显EIT框架造形所将带来的创造活力。于此，还要拿船运的集装箱来相比，则能凸显EIT框架造形所将带来的巨大经济效益。集装箱与EIT框架造形都具备<简单造形、内涵丰富、无限重复>三项特质，将会带来巨大经济效益。

[#711]基于共同造形轮廓、开发者自行定义内涵，并有常用的造形之间的组合规则，组合出巨大的框架；如同许多造型相同的风叶，组合出一遍美丽的树林。

[#712]在汽车业里，从来无人会奢望一部汽车是全能的；既能在沙滩、街道上跑，又能在高山雪地里跑。然而在云产业、互联网、电信业里，有许多人迷信于神话中，期盼软件APP是全能的；能在众多硬件、平台上跑。EIT造形让人人从神话世界回归到产业的实境中，让神话梦想变为事实；或许你也会说我自己正在说神话。

[#713]变化点的确认常常受架构师观点和视角的影响，站在超然角度分析别人眼中的变化点；就如同孔明撰写一篇：三国战局对策，既不是站在刘备视角；也不站在曹操或孙权视角；有分析没设计，就不是流传千古的<隆中对>了。

[#714]造形与华人创意。历史上华人有许多精采的造形创意。之前提到的<唐诗4句7言>就是其一；四合院造形也是；在绘画等上还有许多。只是在组合上较少着墨。什么是组合规律呢? 例如四合院可以无限组合和扩展：院中有院的树状组合；唐诗如白居易的<琵琶行>是7言绝句的线性组合；软件上的XML也是树状组合。

[#715]@让您成为杰出架构师 太阳系有九大行星，从其运行轨迹而观之，其单一造形就是椭圆形。每个造形都含有两个元素：太阳和行星。如果太阳系本身不是一位出色的几何学家，那么一定有一位杰出的几何学家创造了太阳系。更多新思维：http://t.cn/8FbhmdD

[#716]<<组件 Vs.接口>> 因为组件是内涵，宜让其丰富化、人人添增其独特性，如果先抽出定形，内涵就被局限了，这样的造形设计就失去<未来性>了。

[#717]未来性不仅仅是允许未来变化；还有分工的意义；因为框架是要框住APP，框架开发与APP开发是<异地><异时><分工>的。

[#718]软硬结合产品的商业模式；例如，基于<减法思维>的规划。甚么是减法呢? 兹做个比喻，一只茶壶有一个手把；那么，请问：1)增添一个新手把; 2)把原来的手把删除；你觉得何者较容易呢? 答案是：后者极为困难；do you know why?

[#719]软硬结合：<在研发、设计、生产做全线的垂直产业整合，....。在产业越来越分工细化的今天，也有越来越多的厂商开始选择垂直整合，目的是建立自己独有的用户体验，将软硬件的性能优化实现最大化，在产业价值链上形成别人无法取代和复制的话语权。>更多新思维：http://t.cn/8FbhmdD

[#720]<MWC 2012：逃不脱的硬件魔咒> 终端是云服务的出海港口；唯有出色的终端才能决战海外；唯有深度软硬结合，才能创造好摸好玩极具亲密感的终端。或许应该逃脱云计算的魔咒，拥抱终端(硬件)看云层，才能看到彩虹。

[#721]商业模式是可获利的策略(profitable strategy)，还要填入实际行动的时间和当时外在环境要素，才能形成会赢的战术，再反过来调整策略资源，让战术效益极大化，并<越来越深入>。更多新思维：http://t.cn/8FbhmdD

[#722]<设计的思路，完全可以设计一个足够用的简单灵活的框架>是架构师的职责(知)；<移植代码>是程序员的职责(行)；不宜要求同一个人的知行合一，应该培养团队的知行合一(个人分工)。更多新思维：http://t.cn/8Fo3z3r

[#723]@成为杰出架构师<没有完美的设计，也不应该奢求完美的设计。> 与<我今年的努力方向，找出缺板，完善自身能力>两者自我矛盾了。只要设计来自有共识的愿景(vision)，而拿现实来检验，其折中就是好事，不会导致<质量高低不同>的问题。更多新思维：http://t.cn/8Fo3z3r

[#724]@让您成为杰出架构师 假装刺猬的猪：没有完美的设计，也不应该奢求完美设计。现实世界中，经常做的是对实现折中。不同能力的人对折中的处理不同，也会导致成品质量高低不同。对领域有深刻认识，对模式背后的原理有自己的理解，不迷信模式和框架的人往往能更好的解决问题----我今年的努力方向，找出缺板，完善自身能力。

[#725]领域(domain)模型是实的、是需求，不是设计师能操作、挥洒的空间。领愈模型如同凳子的面，设计师的专注点在于创造最佳的<凳脚>来支撑<凳面>。由于邓脚不受需求方的<嵌制>，是设计师挥洒和获得自尊的空间；常常PM都会禁止设计师花时间设计凳脚，因为客户没此需求!!

[#726]<碰到客户需求变更的情况>是合理的；但<领域建模>不是美好的手段!!!

[#727]假装刺猬的猪：我们在软件开发过程中，会持续碰到客户需求变更的情况。如果没有领域建模，我们单纯将问题使用直觉将问题解决，那么等到客户需求变更或者有新的需求时，就会面临一个僵硬的前设计！无法在以前的设计上持续深入的优化模型，导致需求变更无法及时深化。设计实现均滞后与变更！

[#729]假装刺猬的猪：简单的场景套上复杂的灵活的扩展性极好的大框架=？我觉得得不偿失。为什么吸取优秀架构的优点时，都急功近利的直接移植代码，而那些珍贵的设计思想为什么不好好想想呢？有了设计的思路，可以设计一个足够用的简单灵活的框架套在简单的场景上，这样无论是效率还是扩展性都会好一些！

[#730]从<管理>角度看，你的看法是合理的。如果管理者一直压缩架构师的自主成长空间，则<合格的架构师难寻>就是永恒的了。

[#731]兼管理、设计、改代码于一身，可能模糊设计思维空间，设计更标准化，更好捏分寸，也可能是灾难。

[#732]<我今年的努力方向，找出缺板，完善自身能力。> 建议你释放<生产段管理>和<编码>任务给其它人，专心架构设计，兼顾规划段和生产段的产品和架构设计，或许这才是真正缺板，和完善之道呢!!

[#733]<设计很可能与具体实现脱节> 设计要兼顾战略与战术；太偏于战术，就会远离战略；可能并非好事。

[#734]如果是<生产段>的设计，<需要扎实的地基>的实践思考是合理的。如果是<规划段>的设计，竞争力、与众不同常常是优先于实践的考虑；如果没能力实践，也可以OEM呀!!

[#735]你还是相信设计与实践必须集于一身；而不相信设计师与开发者思维方式是互补的；兼顾等于间不顾，没有相互检验的设计与实践，可能是灾难。

[#736]如果是<生产段>的设计，<需要扎实的地基>的实践思考是合理的。如果是<规划段>的设计，竞争力、与众不同常常是优先于实践的考虑；如果没能力实践，也可以OEM呀!!

[#737]#先进架构设计思维# <设计很可能与具体实现脱节> 设计要兼顾战略与战术；太偏于战术，就会远离战略；可能并非好事。

[#738]#先进架构设计# 迪卡儿说在其<<方法导论>>一书里写到：我思，故我在。如果我们鄙视是思考设计、崇尚实践生产，我们就不存在，只有手机、电视机存在。所以只能出口htc手机或海尔电视机了。更多新思维：http://t.cn/8Fo3z3r

[#739]基于parts(行人与汽车)和whole(社会)的需要的平衡之目标，架构师就设计出<红绿灯和班马线>，其规范parts之间的接口(interface)，进而细腻订定两者的互动规则(rule) ，如车站、月台、先上后下、排队上车等。上述的接口和互动规范就是架构师的核心职责，在交通系统如此，在软件、硬件系统也是如此。

[#740]@让您成为杰出架构师 #先进架构设计思维# whole-part。架构师思维演练的第一要素是时间：从未来回顾现在。第二要素是空间：专注于领悟The needs of the whole 与 The needs of the parts。例如，街道上十字路口，其攸关的whole 和parts各为何? 其needs又为何呢? 更多新思维：http://t.cn/8FbhmdD

[#742]whole(如社会)和各parts(如汽车和行人)都是<实>个体，各有需求，常常互相冲突和摩擦。如何让化解冲突和摩擦，架构师要设计<虚的虚>结构(Structure)来规范协调。然而虚结构没有行动能力，架构师就创造(无中生有)一些<虚的实>个体来执行协调任务。<虚的虚结构 + 虚的实个体>就称为架构(Architecture)。

[#743]Whole可分为Domain Whole(简称D-whole)和Goal Whole(G-whole)；Part也可分为D-part和G-part。例如一只北京烤鸭是 D-whole，把牠切成两个半鸡，就是两的D-part。在肯德基餐厅里，一只鸡是 D-whole，切成鸡胸、鸡腿、鸡翅就是D-part；但是他的半鸡(和全鸡)是G-whole，因为是由D-part组合来满足特定Goal。

[#744]一颗木瓜是Whole，种子和果肉是两种Parts。种子代表了木瓜树的needs，甜甜果肉代表小鸟的needs。试想大自然如何让它们达到Christopher Alexander所说的 "perfect balance between the needs of the parts, and the needs of the whole" 呢?

[#745]我百思不解，为何软件人员，对于领悟自然界道理的兴趣缺缺，都常要求我直接给软件实例。中华民族文化的核心之一是道家，擅长的就是悟道。

[#746]#IT+Design Thinking# <<缺板>>，如何知道自己缺甚么板，才是关键。缺板的<补足>并非关键，因为很容易找到别人来补足。

[#747]在微软全盛时期，Bill Gates 师法自然，提出DNA、神经系统等。领悟自然界道理，有助于认识自己的<缺板>，而不是<短板>。短板不一定是缺陷，而缺板可能是灾难。架构师关键职责是找出缺板。当你在写文章或写书时，关键的是要写出自己所该知而未知的，不要掉入自己已知的细节黑洞里。know unknown !!

[#748]自然界生物之设计，其主要限制是<信息的有限性>。软件业框架(Framework)之设计，其主要限制也是<信息的有限性>。悟道，非常有助于领悟软件(应用和平台)框架设计之道。信不信由你! 更多新思维：http://t.cn/8FbhmdD

[#749]<知道>自己缺了那快板，是最关键的、最重要的；不必急着去<补足>缺板，那并不一定重要，也不一定要自己为之，重要的事不一定是急事。

[#750]这是视角不同。就架构师的角度而言，他的职责是：设计组件(component)造型；就编程者而言，所有的软件都是bit构成；他不必关心架构造形。更多新思维：http://t.cn/8FbhmdD

[#751]@让您成为杰出架构师<<架构师思维练习>> 悟道。自然界生物之设计，其主要限制是<信息的有限性>。因而自然界之道是：单纯造形、内涵不同、无限重复。例如，人的手掌，其造形简单、细节纹路不同，无限重复；树叶也如此。如果软件架构也如此，必然具有旺盛生命力，例如OO技术里的Class, 造形简单、个个内涵不同、无限重复。

[#752]唐诗的7言绝句中的<句>就是一件很好、美丽创意的文词<造形>，它具有：简单造形、每句内涵不同、无限重复。愈能将这种创造新的造形的思维习惯发扬光大的朝代，社会生命力就愈旺盛、社会愈和谐。更多新思维：http://t.cn/8FbhmdD

[#753]小米把终端(硬件)产品当作战略物资，网络(软件)服务作为战术武器。唯有战术能在战场上获利，战略支持会赢的战术，让战术效益极大化。如果网络(软件)服务是小米的<会赢的战术>，则小米的愿景是合理的。

[#754]过去大家开发平台或应用框架(Framework)时，都采取"分析、抽象"的途径，一心一意追求通用性、稳定性；EIT门派抛弃这项思维，采取<师法自然>途径，追求<造型简单、内涵不同、无限重复>的上帝造物法则。这项方法来自台湾框架设计联盟的研发项目，目的为了促进IT业迈向软硬结合之路。

[#755]我一直关注<整合>；身为华人思维习惯：<分析>辨认事物而生知识，<抽象>而归纳出较共通性(华人信以为就是道)。华人擅长<分>与<抽>之外，还欠缺<合>。基于我在美、欧、日将近十年生活中，体会到华人需要把<合>的短板补起来。例如，肯德基的半鸡是组<合>出来的；而全聚德的半鸭是<分>解出来的。

[#756]从应用而观之，面向对象(Object-Oriented)的主角是Object；从软件架构而观之，OO的主角是Class。这Class具备<造型简单、内涵不同、无限重复>特质，这依循上帝造物法则：信息局限性(Information limitations)。它具有无现活力和巨大商业潜能。多年来，让我百思不解的是：为何华人对此物的发现不感兴趣?

[#757]名人Will Rogers说：不是那些我们所不知道的事情带给我们麻烦；而是那些我们信以为真，但却实际上并非如此的事情(假设及其推论)。

[#758]蒋友柏谈品牌：品牌可以分成品味、品性、品格三个面向，缺一不可。成功的品牌是一种病毒，就如同"爱"一样，当市场知道它后，愿意靠近它、了解它、进而爱上它。 ~~ 摘自 <<蒋道设计>>一书，蒋友柏(蒋家第四代) 着。

[#759]Whole-part与有机次序(Organic order)。软件设计模式(design patterns)的概念是源自著名的建筑学家Christopher Alexander。他说："We define organic order as the kind of order that is achieved when there is a perfect balance between the needs of the parts, and the needs of the whole."

[#760]Italk新经济沙龙：回顾【一孔之见：员外和长工】与高焕堂老师谈话，我常常是这样：高老师，您刚才说的是不是这个意思？然后我把我的理解，用我的语境再说一遍。因为高老师确实是很上心，很会思考，常常出乎意料，常常让你醍醐灌顶

[#761]在架构师心中，攸关街道十字路口，有两种parts：行人与汽车；并且有一种whole：城市社会。试想，各part的needs是甚么? 该whole的needs又是甚么? 如何才能让它们达到Christopher Alexander所说的 "perfect balance between the needs of the parts, and the needs of the whole" 呢?

[#762]设计API就是设计别人；相对上，开发AP就是被设计而不自知。API是不平等的协议或条约，如同马关条约、南京条约。掌握API制定权是非常重要的。最近两个月，我在台北闭关写书，书名：<<如何开发Android框架和API。>> 其中API就是接口，框架支撑API。更多新思维：http://t.cn/8FbhmdD

[#763]whole(社会) 的need是：<和谐>。part(行人)的need是：安全过马路。part(汽车)的need是：顺畅行驶。如何实现Christopher Alexander所说的 "perfect balance between the needs of the parts, and the needs of the whole" 呢?

[#764]<英国前首相撒切尔夫人曾说：今天中国出口的是电视机，而不是思想观念。> 近代中国人喜欢贬视<拥抱愚蠢梦想>的思考者，而尊崇追求<看得到摸得着>的实践者。因此，只能出口电视机。http://t.cn/zOPVBEA

[#765]在iPhone、iPad产品生产上，美国(苹果公司)和中国(富士康)是两个parts，那么你知道此情境下的whole为何呢? 三者的needs又是甚么? 如何达到完美平衡呢? <谁>掌控这项平衡? 利润有如何共享与分成呢?

[#766]#架构师思维练习# 需求(Requirements)与设计(Design)有甚么关系呢? 目的关系(1)：设计支撑需求；设计是手段，需求是目的。目的关系(2)：需求检验设计；需求是手段，设计是目的。两者都对，但是要留意来源关系，如果设计是<基于需求(requirement-based)>应是错的；亦即，设计不应从需求衍生出来。

[#767]如果D从R衍生出来；则拿R来检验D的有效性就大大降低了。所以，美国大学通常都会要求自己培养出来的博士学生，必须先到别的学校去教学，才受欢迎回母校当教授。因之，如果D来自R，则R就无法有效检验D；因此D不应从R衍生出来。

[#769]#先进架构设计思维# 还是有人再问到可能性与机率性的区别。<可能性(possibility)>是指一个事件无论其发生机会有多渺茫，它仍然可能实际发生；领导者常关注它万一发生了，可能导致的灾难性后果。<机率性(probability)>是指一个事件在未来被人预期会发生的或然率；管理者常视同一件事情的成功机会。

[#771]#先进架构设计思维# 创意者。环球影城副总裁Hettema说：<创意者有三种。第一种是能想出好点子的人，解析问题并提出解决方案。第二种人能举一反三，看出其中关联，然后将解决方案应用到另一个问题情境上。第三种人能在脑海里将整套系统方案与世界概念化。想做出优质电影，三者缺一不可。>

[#772]#架构师思维练习# 删除法。开发者和管理者，常凭<过去>经验而挑选一条看来成功机率性较高的路径X。架构师常从未来回顾现在，很容易看出路径Y才是抵达未来目标最佳路径。此刻架构师不能专注于正面说明路径Y优于X，而是要专注于: 1)清晰叙述未来目标；2)找出事实删除路径X。如此才可能说服他们放弃X。

[#773]#架构师思维练习# Bono思考法：县太爷想娶姑娘为妾，故意逮捕她父亲。村长约定公开抽石子决定。隔天众人围观，村长拿一个袋子将放入两个黑白石子让姑娘抽取其一，若抽到黑色就必须嫁给他，反之不必。此时大爷从地上捡取两颗黑色石子放入袋，只有姑娘看见，却不敢吭声以免激怒大爷。请问姑娘如何应对?

[#774]如果姑娘被困住了，表示姑娘心中有一个假设(assumption)：众人要看我抽出来那颗石头的颜色。因此姑娘逃脱不了自己的思维束缚。

[#775]假设(assumption)。这个思考法练习，目的在于探讨，大部分人面临突发状况，会一时被困住，不知所措，任人摆布。重点在于：为何会被困住呢? 原因是甚么? 可能与自己的思维习惯息息相关而不自知。意谓着人们思维习惯里蕴藏了许多隐晦的假设，常常让自己寸步难行。更多新思维：http://t.cn/8FqOSGr

[#776]有一家百货公司贴出公告：<本周末下午2:00准时举办上空泳装选美大会。> 周末到了，吸引了众多男士前来观赏，选美尚未结束，男士们都失望地走光光了。Why? 这些笨男士们当时心中有个Assumption：选美大会参加者必然是女性。这并非真理，但是自己当时信以为真，而未曾反思，才变笨男士。

[#777]新年初一阅读<<呆伯特法则>>一书，其写到：有些公司藉由调整经营计划来追求所期望的未来，这常常是徒劳无功的。因为调整计划背后的假设(Assumption)部分，便能获得同样的效果。别忘了，未来是建立在假设之上(the future depends on assumptions)，而假设都是你自己编出来的。没有必要自己绑住自己。

[#778] #EIT架构设计思考# 我认为，改变架构师对 {基类 / 子类} 造形的视角，让架构师更有效支持敏捷，可大幅提升敏捷流畅性，是有价值的。同样的{基类 / 子类} 造形，却是extends关系，这是1996年诞生Java时就有的。架构师本来就会注意：形(Form)与视角(View)的关系。

[#779] @让您成为杰出架构师#IT+Design Thinking# 现在主要的议题是：如何培养架构师的思维去设计这种组合架构，来配合敏捷跌代，提升敏捷的流畅性。更多新思维：http://t.cn/8Fo3z3r更多新思维：http://t.cn/8Fo3z3r

[#780] <继承和接口，反应了框架的构建思想，简单但有代表性> 很好的注释。我还想提出，架构师除了关注架构的涵意之外，还要注重设计思考，例如：当基类不再是"抽象类"的系统情境下，这样的基类是如何设计出来的呢? 我们惯用的 "抽象思考" 是不是反而成为一种偏执呢? 也可能是阻碍敏捷的因子呢? 值得反思。

[#781] #EIT架构设计思考# {基类 / 子类} 是软件开发者人人知晓的最基本软件架构造形(Form)，但是人人都能以不同的视角(View)去看它。其中，更多的是，大部分人一辈子都偏执于单一的视角去看它。各项观点都不是本质或真理，而只是视角或观点而已。各项观点都没有对与错；唯一错误的可能是：偏执于单一观点。

[#782] #EIT架构设计思考# <加个部件的基类>，也是 {基类/子类} 的造形，还是一样的设计思考问题：这个部件的基类，与部件子类之间是 "抽象关系" 吗? 谁调用谁? 抽象些什么? 是不是又要找到几乎完整的子类之后，脑海里才能进行抽象思考，是不是又违背敏捷的 simple solution原则呢?

[#783] @让您成为杰出架构师#IT+Design Thinking# 即使是身为 "码农" 的App开发者，也不应该继续坚持从 App看软件世界视角，因为这样就无法知彼知己，扩展视野了。更多新思维：http://t.cn/8Fo3z3r

[#784]过去一年来，我在面对 {Android + 敏捷} 的谜题上，我逐渐发现这个 {基类 / 子类} 基础造形的特别视角，正是这项谜题的答案。于是我称之为 EIT造形，在外观上是传统的{基类 / 子类} 基础结构；但是其幕后设计思维是完全不同维度的；而且对敏捷的顺畅性具有决定性的影响。于是我就提出来与大家共享。

[#785]回复KorukH: 我年轻的时候，处处想把IT智能应用到别的行业，后来觉得是"吃里扒外"；决定改邪归正，从各行业里扒来他们的智慧，充实软件产业的内涵。这句话就是我扒来的。经典的一句话：Don't call me,I'll call you back. 这是好莱乌大明星的名言，是我把它拿来软件业而已。

[#786]我也发现： "Call back" 这个名词阻碍了架构师的思维视角。例如，谁才是老大呢? 谁启动这一串的相互之间的 "call" 呢? 如果Call back 隐含了：子类(App)里有个main()函数，它是主动发出第一个call的一方。我认为就误导了架构师的思维视角，是不好的。

[#787] #EIT架构设计思考# 许多人放不开App为主的心理，承受不了身为App开发者沦为 "配角" 的心理失落感。就不容易 "知彼知己" 看到整体和全貌；也就不容易找到架构设计的新视角，调整产业或企业的脚步和方向，和新落脚处。例如，下图的<E>和<T>谁是老大呢? 谁call 谁? 那个方向才是call back呢?

[#788] IT专家网:哪个方向才是call back呢?回复IT专家网: A先call B, 而B才call back to A。这是一般的合理说法。所以应先厘清谁先call。通常，大家认为App是先call平台，平台才call back to App。这是古典平台的情形，在今天的framework-based平台，是由平台先call App的。

[#789] #EIT架构设计思考# 在软件的世界里，App早已经沦为 "配角"。例如，Android的App里没有main()函数，没有主控权；再如，App里的Activity、Service的子类的对象都不是App自己创建的。失去了主控权，连自身的生杀大权都 "身不由己" 了。所以软件架构师应该放弃从App看世界的古典视角。

[#790] #EIT架构设计思考# 基于传统的面向对象思维，会认为基类(Thread)里的函数是从多个子类之中所抽象出来的；尤其是抽象的run()函数。如此，就很难理解图里的runnable接口是如何设计出来的。这种抽象思维比较难以搭配敏捷开发的跌代过程。

[#791] @让您成为杰出架构师#IT+Design Thinking# 敏捷的精神，偏向于UML是代码的图形表示。或是坚持1990年代的UML图形表示呢? 我是偏于前者，代码就是 {基类 / 子类}的结构，例如Android、iOS的代码都是如此。这是视角问题，不是真理问题。取决于代码的 {基类/子类}结构是否需要与UML一致的问题。http://t.cn/8Fo3z3r

[#792] #EIT架构设计思考# 一旦软件架构师采取了新潮的 "创新组合" 视角，除了能有效支持敏捷跌代过程；还能够有效促进软硬结合设计。例如，下图左边是：主硬件 + Dongle插件 + 血压计配件。右边则是以 {基类 / 子类 } 基本软件结构来整合上述的硬件模块。这就是典型的软硬结合产品；其中，软件是整合的主角。

[#793] {基类 / 子类} 结构，是传统面向对象的抽象视角，从已知的子类里抽象出基类。附图右边的 {基类 / 子类} 结构则是已知的基类，来包容未知的插件和配件(医疗仪)。同一种结构表达两种涵意。

[#794] #EIT架构设计思考# {基类 / 子类} 结构的用途之一。目的是：A(手机) 将来需要与B(医疗仪器)沟通；然而，在开发A时，B是未知的，而且B的接口也未知；如附图的左边。于是，采用 "子类插件" 结构来担任未来的绑定(Binding)任务。

[#795]设计模式是1995年写的，当时还是以inheritance来看{基类/子类} ；1996年Java出来，已经加上 extends 视角了。GoF设计模式是基于古典视角的。

[#796] <前期架构建模和敏捷迭代并不抵触> 这是目的，希望架构设计能配合敏捷跌代，而不是敏捷跌代反过来配合古典抽象思维下的架构设计。前天撰写基类，昨天撰写子类，今天早上compiling，下午运行(runtime)时才去执行基类代码(子类名称昨天已经定案)，去创建子类对象，是可行的呀。

[#797]例如， Android里的 class HelloService extends Service { ... }; 到底谁来创建HelloService子类的对象呢? 如何创建呢? 古典抽象思维才偏执于：{ 基类 / 子类 } 一定是继承。新潮视角下，{ 基类 / 子类 } 结构也能是组合呀 !!

[#798]架构师是否需要考虑代码结构呢? 代码结构就只有一种：{基类/子类} 结构。我主张任何架构设计必须能直觉地落实为代码，对敏捷开发比较有帮助。

[#799] @让您成为杰出架构师#EIT架构设计思考# 在 {基类 / 子类} 基本结构里，到底是有谁来 "创建" ( new ) 子类的对象呢? 这是许多App开发者所忽略的视角，却是非常重要的。http://t.cn/8FbhmdD

[#800]从古典的抽象视角来看，基类是稳定的。从新潮的 "组合创新" 视角来看，基类可以是善变的，基类可以包容多变的通信协议。所以，基类不一定是抽象类，这才能有效支持敏捷开发。

欢迎访问 =>高老师的ADT技术论坛

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

ee ee

<<看上一集-------看下一集>>

IT架构设计_隽语集(EIT设计模式_0701)相关推荐

高老师的架构设计_隽语集(CC_1201)
前言: 平台(操作系统)是轿子,不一定要自己做轿子,会做好轿子的人处处都有,但是要我们自己能坐上轿子爽快一下才算数:而且坐上去之后,有人争先恐后来抬轿才算成功.如何忽悠别人来大力抬轿(且心甘情愿)是心 ...
高老师的架构设计_隽语集(DD_2101)
前言:使用"框架的插件管理器" 管理好业务逻辑插件,包括:插件定义.插件创建.插件配对.插件Callback(含同步与异步)等等.然后,让 HTML5幕后的WebView事件能传递 ...
高老师的架构设计_隽语集(BB_0751)
前言:基于parts(行人与汽车)和whole(社会)的需要的平衡之目标,架构师就设计出<红绿灯和班马线>,其规范parts之间的接口(interface),进而细腻订定两者的互动规则(r ...
IT架构设计_隽语集(Design Thinking _0801)
前言:许多架构师追求稳定.可靠.不变的系统结构:这常常导致敏捷开发的困难:所以我主张:架构师要以接口(Interface)为焦点,以组合创新为依归,就能与敏捷完美组合了.在移动应用和软硬结合应用上,我 ...
IT架构设计_隽语集(Design Thinking _0901)
前言:架构设计的主要流派有二:1) 抽象思维派:致力于抽象出稳定.可靠.不变的共同性架构:亦即,追求<万变不离其宗>的宗.2)组合创新派:致力于组合出具体独特性的创新架构:亦即,追求< ...
高老师的架构设计_隽语集(BB_0901)
前言:架构设计的主要流派有二:1) 抽象思维派:致力于抽象出稳定.可靠.不变的共同性架构:亦即,追求<万变不离其宗>的宗.2)组合创新派:致力于组合出具体独特性的创新架构:亦即,追求< ...
A段架构设计_隽语集(Business Thinking _1301)
前言: 就内容产业而言,让硬件和软件两个产业的创新能量,能够成为内容产业创新的助力,是多么的重要呀! 过去,内容产业只想屏蔽软硬件平台的创新差异化来降低内容的调整成本. 内容产业如何帮助硬件产业呢? ...
高老师的架构设计_隽语集(DD_1801)
前言:管理者的Requirement-based.User-centered.Test-Driven视角只是通往最佳用户体验的众多<途径>之一,不是唯一途径.架构师基于互补视角(例如Vis ...
A段架构设计_隽语集(IT+設計思考_1801)
前言:管理者的Requirement-based.User-centered.Test-Driven视角只是通往最佳用户体验的众多<途径>之一,不是唯一途径.架构师基于互补视角(例如Vis ...

IT架构设计_隽语集(EIT设计模式_0701)

IT架构设计_隽语集(EIT设计模式_0701)相关推荐

最新文章

热门文章