前言：这是2003年我在日本东京工作时，提出来的<Java+C>多层平台架构设计的十项主要原则，并且独创了LW_OOPC语言来实现实现这十项原则。当时，我担任CSA职位，基于这十项原则来提醒我带领的架构(设计)师，也让我的架构团队能取得“设计概念的一致性(ConceptualIntegrity)”。去年，我到华为公司的大师讲堂，对华为架构师团队提供讲座(培训)时，也提到这些原则(只是当时还没改写为中文)

高老师陪您成长...

ee                                                ee

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

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

ADT推广期间，加入ADT会员，享有更多优待 =>加入ADT会员

EE                                                EE

<Java/Hbase + C>云平台架构设计_十项法则

----在日本，这十项法则被归类于“B段架构设计法则”；此外，还有两大类：

• A段架构师十项<设计思考>步骤

------请参观：EIT仙境城堡-------------

• AB段架构师十项演练步骤

------请阅读：智能＆大数据时代，架构师思维的十个步骤和演练

关于OOPC，请参阅：

1. 高焕堂老师于2008年出版的：<<UML+OOPC嵌入式C语言开发精讲>>

2. 華為公司 金永华 介紹新版LW_OOPC的杂志文章

url=>http://blog.csdn.net/juniorhope/article/details/5719107

這是，于2010年由国内华为公司的金永华先生继续扩充，推出更新版本。

目前为全球LGPL协议开源软件：url=>http://sourceforge.net/projects/lwoopc/

EE                                                EE

这十项原则是：

#1.<Java+C>多层Framework-based平台架构设计的天字第一号法则是：

好莱坞大明星原则(Don’t call me, I’ll call you back!)。

请参考：平台框架开发的<好莱坞大明星原则>

#2. <Java+C>多层Framework-based平台架构设计的天字第二号法则是：

共相与殊相并存法则。也就是<通用性接口>与<特殊性接口>的銜接法则。

說明：通用性接口意味着，众人可以共享的接口。由于通用性(或共享性)，框架开发者可以藉单一的通用性接口来<包容>形形***的特殊性接口；具有标准化接口的<减法设计>效果，但又不会减损特性用户或App对特殊性接口的需求。兼顾标准性(共相)和特殊性(殊相)的，是框架平台设计的重要指标；这是任何框架开发里，都必须面对的高度挑战性任务之一。而且，好莱坞大明星透过这通用性接口发出调用信息。

请参考：

1. 认识框架的通用性接口(一)：以Android的IBinder接口为例

2. 认识框架的通用性接口(二)：以PhoneGap的IPlugin接口为例

3. 掌握框架API，决定App归属权(高焕堂 安卓开发者大会演讲稿)

4. 框架通用性接口创造了<重构(Re-factor)自由度>

5. 框架的通用性接口设计(一)：内部<I>的设计方法

6. 框架的通用性接口设计(二)：外部“CI”的设计方法

7. 亲自设计<通用性接口>

8. 观摩Android最高权力的Context通用性接口

9. 通用性接口应用范例：手机与TV的多机整合

10.通用性接口与EIT造形的关系：以Android的Content Provider接口为例

#3. <Java+C>多层Framework-based平台架构设计的天字第三号法则是：

协天子以令诸侯法则。

說明：基于EIT造形做为设计通用性接口的起点。此法则包装通用性接口，来得出比较特殊化的接口，提供给买主或用户的更个性化而贴心的服务，也减轻地头蛇(如App开发者)的负担。此外，地头蛇(如App开发者)也能运用相同的技巧，将强龙提供的接口(含通用性或特殊性接口)包装起来，改为自己定义的新接口，能大幅提升地头蛇的软件模块的跨平台性质。地头蛇定义的特殊化接口屏蔽了强龙(天子)定义的通用性接口，提升自己能跨(天子)平台的能力。所以称为：协天子以令诸侯法则。

请参考：包装通用性接口，定义特殊化新接口

#4. <Java+C>多层Framework-based平台架构设计的天字第四号法则是：

Command flow和Data flow分离法则。

說明：软件有两种flow，一种是Command flow；另一种是data flow。例如控制camera的信息是Control flow；而传送preview视像的是data flow。可以透过command flow API去通知两端的模块，动态取动两端插件，透过动态API(如Config文件提供)串接两端；静态Command API支撑动态Data API。例如，在建置大数据平台时采用Hbase。这H base是以Java开发的，其提供了Java基础接口，在C层则使用thrift机制。如果咱们的C层模块想存取Hbase时，使用的技术是：C调用jni，再调用Hbase的Java接口(亦即C->jni->Java)，但这种架构方式，会导致性能下降，该如何解决这个议题呢? 这个议题可以将Command flow与Data  flow分开来。并且离清你的Data Source是C层(可能是先已经从Hbase查询出来，放在C层了)或是还在Java层的Hbase里。如果Data Source是在Hbase里，其thrif接口就是Data Source接口。因此，Data Source接口都在C层，而你的Client (Data destination)是在C层。于是：

• Data flow是C->C，不要经由Java层，效率就极高。

• Command flow可以经过Java层，有助于控制点放在Java层。

• Command flow：C->JNI->Java接口，要求Java模块把HBase端的C接口传递给Client。

• Data flow: Client调用HBase端的C接口(若跨进程，可透过IBinder接口)，取得data。

#5. <Java+C>多层Framework-based平台架构设计的天字第五号法则是：

集装箱式抽象法则。

请参考：

1. 集装箱思维：在革命性转折点，经常出现它的身影

2. “集装箱式”抽象视角的演练

3. 高老师的<集装箱>思维，2008年初预测Android蓬勃发展

【附注】

----1993年我在美国科罗拉多大学，听了一位德国籍教授演讲“中华文化的生命力”，他的确非常精通中华文化之道，他提到了儒家哲学大师牟宗三的“良知的自我坎陷说”主张。牟宗三在其1961年的经典巨著《理性的运性表现与架构表现》书里，就提到了：在中华文化的生命里，

• 只有「综合的尽理之精神」，而缺少「分解的尽理之精神」

• 只有「理性之运用表现」，而缺少「理性之架构表现」

• 只有「理性之内容表现」，而缺少「理性之外延表现」

----这提醒了在儒家文化熏滔成长的我，用心反思软件架构的分解(Decomposition)思维是否达到原子(Atom)造形层级，这可能是分解尽理之精神。然后，在架构(Architecture)思维里，是否设计出简单的组合韵律，基于简单造形和清晰组合规律，从简单中组合出气象万千的架构。这可能是理性的架构表现。最后，在抽象(Abstraction)思维里，是否将内涵(内容)与造形(外延)抽离开来，也就是集装箱是抽象视角。这可能是理性的外延表现。

----恰好，在1995年Gamma的GoF设计模式(Design patterns)一书出版了，将原子层级的类(Class)造形，组合成为较大的模式(Pattern)造形。于是我就继续将设计模式组合出更大的框架(Framework)造形，并且在1995年在台湾出版了全球第一本框架设计的中文书(台湾物泽出版社出版)。

----随后于2012年，我正式提出EIT软件代码造形；并于2013年获得国际学术界的高度认可，受邀于<2013清华设计管理国际大会>进行论文发表。以上只是提供给同样在儒家文化熏滔成长的软件人员，做为茶余饭后的闲聊议题而已。

也请参考：拿张之洞<学贯中西造形>来演练<Java/Hbase + C>云平台架构思维

#6. <Java+C>多层Framework-based平台架构设计的天字第六号法则是：

基类创建子类对象法则。

說明：此法则的用意：

1.在开发阶段，基类与子类是分公开发的，基类由强龙(好来呜大明星)开发；而子类则由地头蛇开发。这是从类别(Class)的视角来看的。并在编译时，会将两者(基类和子类)一起编译，进行接口的检测(例如参数型态)，确保结构上是可对接的(符合接口协议)，并结合为一。到了执行阶段，由基类和子类共同合力创建一个对象(如鸡蛋)，就是一个子类对象(蛋白)，其内部包含了一个基类对象(蛋黄)。

2.此法则提醒设计师：好来呜大明星(强龙)必须拥有该对象(鸡蛋)的诞生权力，才能在执行段阶段，有效掌握基类对象，来发号司令(I will call you)。

3.一旦，好来呜大明星掌握了基类API(接口)，拥有结构面(开发阶段)的控制力；也掌握了对象的生杀大权，拥有逻辑面(执行阶段)的控制力。这两道力量确保了好来呜大明星的强龙(真命天子)地位，拥有100%话语权。

请参考：

1. 框架API：区别主动型与被动型API

2. 框架API：制约力量的强弱等级

3. 框架如何创建App子类的对象(一)?

4. 框架如何创建App子类的对象(二)?

#7. <Java+C>多层Framework-based平台架构设计的天字第七号法则是：

把基类当礼物送别人法则。

說明：此项法则的用意在于：

• 在编译时，基类必须与子类合并，所以基类必须对地头蛇开源(给源代码)。

• 基类的API像鱼钩，常常必须丢向于鱼群，如同礼物送人。

• 基类礼的“默认行为(Default Behavior)”就像鱼饵，用来吸引鱼群。

• 把基类软件(如鱼饵)是要送人的，不是要卖钱的。送人的礼物要极为用心，做的精致；不仅做到可用、能卖钱就好。

• 鱼群有些在近海(如后台服务器)上，有些在远洋(如移动终端)，基类常常是征服天下(或远洋)的利器。

请参考：

1. 掌握框架API，决定App归属权(高焕堂 安卓开发者大会演讲稿)

2. 框架的鱼饵：默认行为(Default Behavior)

#8. <Java+C>多层Framework-based平台架构设计的天字第八号法则是：

从简单组合出复杂法则。

說明：此项法则的用意在于：

• 这是集装箱抽象视角的软件代码体现：将基类视为一个集装箱，是一个造形(Form)，内部的代码(默认函数里的代码)就是集装箱里的货物，也就是基类造形的内涵(Content)了。

• 集装箱内部(内涵)是复杂多变的，但集装箱的组合规律反而是简单清晰的。

• 基类就是原子(Atom)层级的集装箱，也可以组合成为较大(分子层级)的集装箱，甚至更大的集装箱(如集装箱货轮)。这就是从简单组合出复杂。

• 同理，基类和子类(造形)可以组合出EIT造形，也可以组合出较大的模式(Pattern)造形，甚至更大的框架(Framework)造形。

• 基类API(或EIT造形的<I>)是鱼钩，可巧妙地重复地组合起来，成为一个巨大的鱼网；就成为软件框架(或平台)了。

• 此项法则提醒设计师要关注到原子层级的简单结构(无论是自己创造或是别人设计的造形)，并寻找简单清晰的组合规律，才能从简单中组合出形形***、气象万千的可靠系统架构(如集装箱货轮)，来容纳复杂多变的内涵(货物)。

• 基于从简单中组合出复杂；让人们能透过简单形式的集装箱，来掌握复杂的内涵(天下万物)。

请参考：从复杂设计出简单，从简单来掌握复杂

#9. <Java+C>多层Framework-based平台架构设计的天字第九号法则是：

从简单中叫出复杂法则。

說明：此项法则的用意在于：

• 用户体验就是用户获得从简单中叫出复杂的满足感。

• 当我们疯狂地迎接智能化设备带来的更多新功能时，就意味着大家忙着做加法设计。此外，当我们疯狂地抓取各地异构大数据时，也意味着大家忙着做加法设计。此时，杰出设计师的关键任务就是减法设计。

• 在上一条法则里，设计师运用其创意，设计出简单(减法)，然后再从简单组合出复杂(加法)。

• 此项法则提醒设计师：其设计上的创意(减法或加法)，都需要以用户要求的简单来检验，让用户获得从简单中叫出复杂的满足感，才能有效提升用户体验。

#10. <Java+C>多层Framework-based平台架构设计的天字第十号法则是：

没钱就改版，改版就有钱法则。

說明：此项法则的用意在于：

• 提醒设计师，在建立双层(Java层和C层)框架平台时，心境上必须时时关怀下层框架和模块的变动自由度。

• 这又称为“万里长城法则”，长城的重心在于关口(如山海关)而不在于城墙本身或城墙内部。意味着，框架(和基类)的重心在于API(简单的外形)，而不在于复杂的内涵。

• 关口(API)的目的是去控制塞外(通常位于上层)游牧民族的行为，来确保关内(通常位于下层)居民的安居乐业(自由起居，不受塞外的干扰)。

• 特别提醒设计师：不宜拿建筑物的地基，来比喻下层框架或平台，因为人们往往认为地基必需稳定，上层的房子才会安全可靠。这项比预严重违背“集装箱式抽象法则”。

• 反之，可以拿一棵树来做比喻。上层是数页，中层是树干，下层是树根。中层力求稳定，其做法是：有效规范(限制)上层树叶的变动幅度，来保护下层树根的承受压力(限制)，以便维持树根灵活度(即变动自由度)。如此，这棵树就能健康成长、无限繁荣了。

• 一旦，中层力求稳定(减法)；限制上层的发展(加法)幅度；强化下层成长(加法)的活力。于是，下层框架和模快就能随时PnP(Plug-in andPlay)，迅速新陈代谢，提供给中上层无限的养分。

• 基于PnP的效益，就能带给下层开发者(或供货商)极佳的机会：没钱就改版，改版就有钱。因而底层供货商会争相来抬轿(大力支持整体架构)，好来屋明星自然成为坐轿子的人(而不是自己做轿子，却又自己抬轿子)。

~ End ~

EE                                                 EE