By 高焕堂 2013/07/23
通用性接口与EIT造形的关系：
以Android的Content Provider接口为例
1. 以DB引擎模块为利：确保变动的自由度
在没有通用性接口保护的情形下，让各Client毫无限制地使用DB引擎的接口。这种接口，就DB引擎而言，都属于被动型API，受制各Client端，严重伤害DB引擎的变动自由度，局限了DB引擎的成长空间；如下图：
此时，最常见的对策就是：DB引擎厂商(开发者)自己定义一个<接口类>，提供一个对外的接口，隐藏了DB引擎本身的接口；如下图：
然而，这个<接口类>属于特殊性接口，不同DB引擎的厂商，都有专属的<接口类>；所以不是各DB引擎都适合的通用性接口。比较美好的绝对策是：提供通用性接口给Client端。例如：
这Cursor是Android框架所提供的通用性接口，让App(如Activity或Service等)能透过此Cursor接口来浏览DB里的各笔数据或内容。然而，上图解决了一半的设计问题，对于”open & query”的交互，还是透过特殊性接口。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
即使再增添一个DataPersist类(如下图)，仍然是一样的问题。
解决之道是：让特殊性的DataPersist类，来实践一个通用性的接口(以基类形式呈现)。Android提供一个ContentProvider基类，就是这个通用性基类的角色。如下图：
此时，可以藉由EIT造形来理解上图里的两个通用性接口(一个接口，一个基类形式)；如下图：
其实，就是两个EIT造形的表现而已。
所以，只要你熟悉EIT造形，就有能力设计各种通用性接口了。 [ 认识EIT造形 ] ◆
[Go Back]
