– 适用于Android, iOS 和 Win8 平台

一、概念与手艺

Sec-1. 框架设计之概念和技艺

1.1 概念

      ◆  框架的起源、分层与其「无用之用」效果
      ◆  框架与OS之关系：常见的问题
      ◆  应用框架魅力的泉源：反向沟通技术
      ◆  深入认识控制反转
      ◆  主控者是框架，而不是应用程序
      ◆  现代应用框架：采取广义IoC观念
      ◆  框架的重要功能：提供预设行为

1.2 手艺

      ◆  抽象(无之)与衍生(有之)
      ◆  打造框架：细腻的抽象步骤
      ◆  基本步骤
             ★ 细腻的手艺(一)：数据抽象
             ★ 细腻的手艺(二)：函数抽象
             ★ 细腻的手艺(三)：将抽象类别转为接口(Interface)
      ◆  以Android, iOS和Windows为例，说明黑箱式框架与白箱式框架之设计思维和技艺

1.3 图形表达

      ◆  UML的3种基本图表：类图、顺序图和用例图
      ◆  以UML表达设计模式和框架
      ◆  EIT造形的两种表达：UML图和代码

二、分析方法

Sec-2. 行业概念(Concept)与用例(Use Case)分析方法

2.1 双插式分析

      ◆  跌代(Iterative)过程
      ◆  包含渐增(Incremental)模式
      ◆  依循I&I和Use Case-Driven途径，以 EIT造形来表示接口
      ◆  然后将EIT造形落实为类别和代码

2.2 业务规则(Business Rule)分析

◆ 随着<行业概念>分析和<业务规则>分析，得到更多的业务概念、类别和规则，就以前面所述的<平台&插件>关系来组织和重构
◆ 此架构模式，既能搭配敏捷开发，也能搭配RUP方法

2.3 范例

◆ 以五子棋和拉霸机游戏为例，进行分析演练

Sec-3. 框架接口(API)分析与设计方法

3.1 接口分析

◆ 基本设计技能：把轮胎拔掉
 ◆ 伟大的雕刻师罗丹( Musée Rodin)说：”把不必要的部分去掉”
 ◆ 买主需求：想想为什么(why)汽车架构师会决定把轮胎拔掉呢? 其背后的理由是：买主来了，才知道买主对轮胎的偏好或特殊需求。只有等到买主决定和挑选了轮胎之后，才能将轮胎装配上去。
 ◆ 探索买主需求
 ★ 为什么把轮胎拔掉呢?
 ★ 为什么火锅店的桌子要挖洞呢?
 ★ 为什么餐厅要分开<食谱>与<点菜单>呢?

3.2 接口设计

◆ 在OOP里，将接口定义为一种特殊的类别(Class)
 ◆ 在Java里，将”纯粹抽象类别”称为接口(Interface)
 ◆ EIT造形的接口表示为；可以合并到<E>里
 ◆ 被动型API与主动型API

3.3 接口与商业模式

      ◆  API决定控制权
      ◆  谁拥用接口的制定权，谁就掌握控制点，就能获得较大的话语权
      ◆  从API看控制力量的强弱等级

3.4 EIT造形(一)：容易，插件容纳变化

◆ 什么是插件<T>?
 ◆ 插件(Plugin)的分类；插件与接口
 ◆ EIT造形里的插件<T>

3.5 EIT造形(二)：结构制约，积极掌控插件

◆ 什么是接口? 谁控制?
 ◆ 接口的分类
 ◆ 决定控制权

3.6 EIT造形(三)：组合创新，让整体<飞>起来

◆ 什么是平台<E>?
 ◆ <E>+ = 框架(Framework)
 ◆ <E>是控制点，透过来驱动<T>

3.7 EIT造形(四)：曹操类，协天子以令诸侯

◆ 拿EIT造形搭配Proxy-Stub设计模式，规划Stub类别(曹操类)，制定自己的，让<T>脱离上层<E&I>所牵制；实现”挟天子以令诸侯”的效果

3.8 范例

◆ 以五子棋和拉霸机游戏为例，进行接口设计演练

三、基础设计模式

Sec-4. 一般设计要点

4.1 复习设计样式

      ◆  设计样式的意义、角色和起源
      ◆  介绍常用的GoF软件设计样式
      ◆  常见的设计样式应用情境

4.2 API = 话语权

      ◆  API与UI不同
      ◆  UI是App与用户的交互接口
      ◆  API则泛指软件模块间的接口，可分为：
             ★ SI：本架构与外部系统之间的接口
             ★ PI：本架构与内部挿件(Plug-in)之间的接口
             ★ 一般API：本架构与应用程序(App)之间的接口
      ◆  掌握API定义权，就拥有话语权

4.3 应用框架 = 用来框住应用(App)的架构

◆ 框架的基本组成元素：EIT代码造形(Form)
 ◆ EIT造形的就是API
 ◆ 框架是鱼饵，API是鱼钩
 ◆ 鱼饵是送人的礼物；送越多，拥有市场版图越大

4.4 框架(平台)调用App，不是App调用框架

      ◆  用户并非直接碰触软件(App)
      ◆  App在软件架构里，其地位是最低的
      ◆  例如，从移动终端发信息给云平台时，云端的IaaS层先接到信息；然后才(调用PaaS服务)来将信息往上送；再调用SaaS层服务来将信息送上去

4.5 从<C/S API>到<端/云API>

◆ API是分工的界线
 ◆ 过去，Client与Server是由不同团队分工开发的
 ◆ 今天，谷歌、Facebook、微信等，改变了API、改变了分工，如下图所示。
 ◆ 这称为跨<云&端>强龙企业

4.6 架构师做<分>的决策，开发者做<合>的任务

◆ 肯德基餐厅的厨师做：庖丁(分)解鸡
 ◆ 肯德基柜台人员则做：组(合)出全鸡、半鸡等套餐
 ◆ 分得妙、就合得快
 ◆ 分：无之以为用；合：有之以为利
 ◆ 因<分>而得接口(Interface)，依据接口而快速组<合>

4.7 <分>的时间点：买主来到之刻

      ◆  平台(Platform)设计者，必须重视买主，而不是用户
      ◆  买主来到之前，先做分(即无之)
      ◆  买主来了之刻，才做合(即有之)

4.8 没钱就改版，改版就有钱

      ◆  拥有平台(Platform)者，常采取分层(Layered)架构，适合理的
      ◆  过去，上层模快(开发者)，常常要求下层必须稳定不变
      ◆  今天，上层模块不能要求底层的稳定不变，而是要处处维护底层变动的自由度；这样才能实现：没钱就改版(底层)，改版就有钱

四、进阶设计模式

Sec-5. 进阶设计要点：实例说明

5.1 平台 = 框架 + 引擎

◆ 古典：平台 = (服务)引擎
 ◆ 为了维护底层<引擎>的变动自由度，就采用新架构
 ◆ 于是，得出典型的Framework-based平台架构：
 ◆ 当今的.NET、iOS、Android平台都是这种架构
 ◆ App就是一种插件；应用层也是插件层

5.2 保护 <DB引擎> 的变动自由度

      ◆  传统架构：降低引擎的变动自由度
      ◆  优化架构：加上一个EIT造形
      ◆  EIT造形直接落实为类别(代码)：
      ◆  此架构的控制点在哪里? myDbHelper类别是谁开发的呢?
      ◆  此EIT造形与Factory模式有何差异呢?
      ◆  EIT造形如何保护DB引擎的变动自由度呢?
      ◆  SQLite引擎可以”没钱就改版，改版就有钱”吗?

5.3 后台<业务规则(BR)引擎>的挿件架构

      ◆  首先替引擎设计一个EIT造形，并将成长为框架
      ◆  插件包括3种：App(用户)插件、业务(业主)插件和平台插件
      ◆  当插件增多了，需要设计插件管理机制
      ◆  看似复杂的架构，却只是3个EIT造形的巧妙组合而已

5.4 如何提供<插件接口>给Client

◆ 通常，后台的业务或平台插件的开发者，与Client开发者是不同的；而且开发的时间点也不一样(插件常开发在先)
 ◆ 那么，当Client需要调用插件时，后台如何提工插件接口给Client开发者呢?
 ◆ 即使Client端可以从文件中得知插件的接口，又如何调用呢?
 ◆ 首先，后台<E&I>提供一个通用型接口，内含一个通用型函数
 ◆ 然后，后台提供一个Proxy类别给Client
 ◆ 那么，又如何提供Proxy类别的代码给Client开发者呢?

Sec-6. 观摩框架设计技巧：实例说明

6.1 观摩Android应用框架的设计

◆ ListView框架范例解析
◆ SurfaceView框架范例解析

6.2 观摩iOS应用框架的API

◆ 解析AV框架的API设计
◆ 解析Social 框架的API设计

6.3 Android、iOS、Win8不同平台的需求和限制

      ◆  如何开发Android上层的应用框架
      ◆  如何开发Android底层的驱动框架
      ◆  如何开发iOS的应用框架
      ◆  如何开发Win8的应用框架

6.4 从未来性看这些框架的设计

      ◆  目前决策的未来性
      ◆  具有未来性的框架API设计
      ◆  Steve Jobs的名言：从未来回顾现在

五、落地策略与实战演练

Sec-7. 多层框架：如何在C/C++平台上建立Java框架

7.1 目的

      ◆  让Client端开发者自己来撰写后台的插件
      ◆  于是，后台成为一朵真正的云(Cloud)了
      ◆  一个C/C++平台可以搭配多个不同语言的框架

7.2 做法：以Java为例

◆ 使用JNI(Java Native Interface)
 ◆ 例如，C/C++平台的<业务规则BR引擎>可以搭配一个Java框架
 ◆ 因为C/C++模块(如<业务规则引擎>)可以调用Java函数，所以C/C++平台仍然拥有主控权

7.3 也能用ANSI-C语言来设计框架

      ◆  活用C语言函数指针(Function Pointer)
      ◆  在C语言的struct结构内定义一个数据项(Data Item)¸ 并定义其型态(Type)是函数指针
      ◆  这个struct结构相当于C++的抽象类别了，而函数指针数据项，就相当于是抽象函数了
      ◆  于是，就可以撰写这个struct结构的”子类别”(或插件)了

Sec-8. 敏捷(Agile)框架开发方法

8.1 熟悉高老师的敏捷上层架构(框架)设计方法

      ◆  认识敏捷开发的原则和价值观
      ◆  以敏捷迭代产出云端的接口设计，也产出终端的接口设计
      ◆  将两端的接口落实为EIT造形的程序代码
      ◆  系统之间接口设计完成，展开终端的框架开发
      ◆  继续进行敏捷迭代，开发终端框架的更多EIT造形
      ◆  运用设计模式(Design Pattern)，对EIT造形进行有机组合，成为框架

8.2 细说MCS模式和EIT造形的活用技巧

      ◆  MCS模式如何表达SOA、MDA、云端运算等其它系统架构
      ◆  观摩各种常见的MCS模式系统架构
      ◆  从减法设计思维来看MCS模式和EIT造形的运用

Sec-9. 情境体验式的分组研习和演练

9.1 选择自己(小组)的框架案例

      ◆  案例要点说明
      ◆  订定初步简单方案(Simple Solution)
             ★ 叙述愿景(Vision)
             ★ 订定基础架构策略
             ★ 订定基础需求

9.2 体验敏捷的迭代&回馈过程

      ◆  基于上述简单方案，展开敏捷过程
      ◆  准备TDD方案
      ◆  启动迭代

9.3 运用xMCS模式，设计<云&端>整合架构

      ◆  规划创新的业务情境
      ◆  设计系统之间接口的沟通协议
      ◆  叙述接口的详细规格

9.4 以EIT造形落实上述架构的接口

◆ 挑选适合的设计模式，包括：EIT造形、GoF等模式
 ◆ 减法设计：模式 + 自己的组合风格 = 系统架构
 ◆ 详细规范具有互通性的<系统接口>
 ◆ 以EIT造形的程序代码来实践<系统接口>
 ◆ 返回3.2继续迭代过程

9.5 体验两阶段敏捷的衔接

◆ 基于上述EIT造形程序代码为起始方案
 ◆ 启动<终端框架开发>的敏捷过程
 ◆ 增添一个业务功能
 ◆ 设计新功能的xMCS模式
 ◆ 撰写新功能的EIT造形代码
 ◆ 设计TDD方案持续进行迭代

9.6 进行框架整合测试

      ◆  使用Android平台的测试框架
      ◆  进行功能测试
      ◆  善用Mock机制

9.7 各组成果报告

      ◆  案例目标
      ◆  创新、设计与实作过程
      ◆  进行了那些减法设计、或加法设计
      ◆  成功要点、或失败因素

~ end ~

行业别应用框架(Open API)开发实战_A05课程大纲