Framework-zz-39

By 高焕堂 2013/06/01

[Go Back]

[請指教：高老師的免費on-line教學視頻]

Android & Framework：应用框架与平台框架开发技术

框架支持敏捷(Agile)架构设计

1. 敏捷架构设计的2个关键议题

架构设计如何迅速落实为代码。
架构师如何给自己创造重构的自由度，以及支持App开发者重构的空间。

1.1 迅速落实为代码

依赖两项重要的代码造形：

EIT造形
框架(Framework)

1.2 重构的自由度

分辨一下：<关注未来的决策>与<关注今天决策的未来性>的微妙差异。设计团队如何给自己创造重构的自由度，以及支持App开发者重构的空间，是敏捷架构设计的关键议题。换句话说，架构师不关注未来的决策，而是关注今天决策的未来性。
框架(Framework)并不表现各业主需求的共通性(General)部分；而是去表现组合重构的接口(Interface)部分。框架与内涵(Content)分离，也就是框架与需求分离。框架如同杯子，而需求如同果汁饮料。杯子本身没有果汁，但却提供空间来支持果汁的分与合(即重构)。
可以设计多层框架体系，例如上层框架可以容纳买主(用户)的特殊需求(如App)及其变化；而底层框架可以容纳供货商特殊模块(Module)及其变化。买主App与供货商模块之间可以透过框架的通用性接口来衔接与组合；创造弹性的重构空间。

2. 架构师的视角

以代码造形思考设计；让开发者直接对应到代码。代码造形就如同专块，建筑师叙述如何以砖块组合出形形色色的建筑物；施工者就烧出专块，并按步就班组合起来。
架构师从简单组合出复杂。亦即：造形很简单，内涵可复杂，重复地组合。
让用户获得从简单中叫出复杂的满足感。亦即：优质的用户体验。
框架设计包含两个层面： 1)思考设计； 2)表述设计。
架构师最关键的职责是接口的设计和表述(Represent)了，也就是包含两个层面：1)如何进行设计接口； 2)如何清晰表述接口。之前，我们大部分介绍如何将EIT造形应用于架构的表述上；亦即，架构师藉EIT造形来清晰而明确地传达接口的设计(Design)与定义(Definition)给开发者，让开发者能基于架构而顺利展开后续的详细设计，并迅速落实为代码，进而测试与回馈来驱动敏捷跌代过程。
其实，EIT造形除了用来”表述设计”之外，也很适合于”思考设计”层面上。尤其对初级架构师而言，依循EIT造形的引导，能够找到潜藏不明的，或者能激发创意，无中生有地创造了新的。例如，初级架构师可藉由EIT造形来思考和实践<目前决策的未来性>，创造重构的自由度。

3. 设计通用性接口

3.1 基本概念

EIT造形的很适合做为通用性接口的起点(Simple Design)。
就是将<E>与<T>分离之后的整合点。
<E>与<T>的分离，就是”架构师知识”与”买主知识”的分离。[ 认识EIT造形 ]

架构师知识与买主知识的获取，有时间落差，常依据”买主来到”做为时间切割点。

例如：

3.2 汽车的EIT造形

典型的EIT造形，<E&I>是一起设计的，的定义权属于<E>设计团队的。从<E>的视角来看，此是<E>所专属的。从<T>的视角来看，此是各<T>所共享的；<E>也是各<T>所共享的；亦即两者都是通用性的。<E&I>表达了各买主(或客户)的通用性功能；而<T>则表达了各买主的特殊性需求。通用性的，有两层意义：1) 容纳买主需求(或选择)的未来变化，或容纳新买主的新选择；2) 限制买主的选择范围。例如，买主买了车子之后，未来随时可以改变选择(沙滩、公路或高山)；展现出设计师目前决策的未来性。例如，买主未来决定将车子要到沙滩上跑时，就更换新轮胎，如下图：

再如，买主未来又改变需求，决定将车子开到高速公路上时，就更换新轮胎，如下图：

再如，买主未来又改变需求，决定将车子开到高山雪地时，又可随时换新轮胎，如下图：

此外，EIT造形也限制了买主的选择范围(藉由来限制<T>和<A>)。例如，EIT造形会清晰表述何种<T>才被允许装配上来。例如，下图就不是被允许的了。

3.3 软硬件的EIT造形

其实，EIT造形只清晰地表述出很通俗的<主件、插件、配件>的组合关系而已。我们很容易将上述的汽车EIT造形，对映到软硬件的EIT造形，如下图：

这图里的<E>、、<T>、<A>共4个要素，就对映到通俗的<主件、接口、插件、配件>的组合关系而已。如下图：

兹将上述EIT造形应用于游戏软件架构上，手机游戏框架提供<E&I>，可以让买主(或用户)未来选择各种搭配的云平台。当买主未来又改变需求，决定使用新的平台时，只要随之更换新的<插件>即可了。如下图：

兹将上述EIT造形应用于智能电视(TV)平台上，智能TV提供<E&I>，可以让买主(或用户)未来选择各种搭配的OTT平台(如选择微信或微博等)，就能将家庭里的信息，透过智能TV而推送到微信、微博或Skype等OTT平台的客户端屏幕上。当买主未来又改变需求，决定使用新的OTT平台时，只要随之更换新的<插件>即可了。如下图：

买主在未来时间里，可能会改变他对配件<A>的选择(即改变决策)；每一项选择都是该买主的特殊性需求。于是，买主委托App开发者改写<T>代码来表达<A>的特殊性，并符合通用性接口，来与<E>重新组合起来。未来新的买主来了，让他在的限定范围里进行他对配件<A>的选择(做决策)；其选择都是该买主的特殊性需求。于是，买主委托App开发者改写<T>代码来表达<A>的特殊性，并符合通用性接口，来与<E>组合起来。 [歡迎光臨高煥堂網頁：http://www.cnblogs.com/myEIT/p/3294344.html ]

架构师设计了通用性接口来容纳买主未来决策的改变，这也意味着：设计师的目前决策(决定如何定义接口)具有高度的未来性。 EIT造形让架构师、开发者都具有整体观，间具通用性和特殊性的考虑；因而让整体系统具有高度的未来性和敏捷性。

4. 设计特殊性接口

刚才是基于EIT造形，来做为设计通用性接口的起点。于此，将续述如何包装通用性接口，来得出比较特殊化的接口，提供给买主或用户的更个性化而贴心的服务，也减轻地头蛇(如App开发者)的负担。此外，地头蛇(如App开发者)也能运用相同的技巧，将强龙提供的接口(含通用性或特殊性接口)包装起来，改为自己定义的新接口，能大幅提升地头蛇的软件模块的跨平台性质。

4.1 强龙擅用Stub类

当愈通用化时，就愈能容纳买主更大的选择范围(或空间)。
当愈特殊化时，则愈能提供给买主更个性化而贴心的服务。
设计师如何兼顾未来性(通用性)和特殊性呢? 答案是：擅用Stub类(class)。
强龙撰写Stub类来提供”比较特殊性”接口；其缩小一些买主的选择范围；同时因范围缩小，新增了一些共享性功能，就将新增功能写入Stub类里。
因此，Stub类提供了更特殊性的接口，给予的更多功能，降低了地头蛇(开发<T>)的负担。
例如，一个<E&I>设计如下：

买主选择了Drawer，他委托地头蛇撰写<T>。

<E>透过来调用<T>，间接调用到Drawer的功能。

如上图所示，地头蛇撰写myDraw子类时，必须撰写＂画背景＂和＂画前景＂两个函数的代码。
使用Stub类来包装通用性的IDraw接口。

于是，设计一个Stub接口类，提供一个新接口(含有drawForeGround函数)。
由于IDraw接口不能写入代码，而Stub类则可以写入代码；所以能将共通的部分写入Stub类里。

这时，强龙帮地头蛇撰写了＂画背景＂的代码了；也就是drawBackGround()函数的代码，并放置于Stub类里。
地头蛇已经看不到通用性的IDraw接口了，只要针对新接口去开发＜T>即可。

4.2 地头蛇擅用Stub类

刚才是强龙定义比较特殊的接口，来自己包装自己的通用性接口。
地头蛇也能善用同样的技巧，运用Stub类来包装别人(强龙)的接口，定义出自己的接口。
例如，有一个EIT造形如下：

地头蛇使用Stub类来包装强龙的特殊性接口。

于是，设计一个Stub类，为自己定义一个新接口(含有doDraw函数)。

地头蛇已经看不到强龙的接口了，只要针对自己定义的新接口去开发＜T>即可。

如果强龙像天子，则myStub类就实现了＂挟天子以令诸侯＂的效果，期将天子的接口包装起来，改为自己定义的接口。

5. 结语

强龙透过Stub类而将通用性接口包装为比较特殊性的接口。愈特殊性的接口，其提供给买主的选择<A>的空间就愈小，则<T>的差异性就愈小，因而会有更多的共同性，例如各<T>的都有相同的背景图。新增的共同性就能写入到Stub类里了。
至于地头蛇，则透过Stub类来达到＂挟天子以令诸侯＂的效果，将天子(即强龙)的接口包装起来，改为自己定义的接口；让自己的<T>不受制于天子所定义的接口。大大提升了<T>的变动自由度。◆

[Go Back]

发表于 2013-11-12 13:00 高煥堂.EIT 阅读(164) 评论(0) 编辑收藏举报

常用链接

我的标签

随笔档案