设计原则:小议 SPI 和 API
背景
第一次听说 SPI 是阅读《软件框架设计的艺术》,以后陆续在 Log4Net 和 Quartz.Net中发现了以这种形式组织代码的方式,本位给出为什么要区分 SPI 和 API 的一个思考过程。
从面向接口编程说起
我们在“调用方”和“实现方”之间引入了“接口”,上图没有给出“接口”应该位于哪个“包”中,从纯粹的可能性上考虑,我们有三种选择:
- “接口”位于“调用方”所在的“包”中。
- “接口”位于“实现方”所在的“包”中。
- “接口”位于独立的“包”中。
下面让我们依次分析这三种可能性,如果现实中确实有这种可能性,不如我们就为其起个名字以方便交流。
“接口”位于“调用方”所在的“包”中
我们先想象一个场景,以仓储的接口为例:
我们将“仓储接口”放置于“领域层”这个“包”中,实现放在一个独立的“包”中,我们看DDD大师的实现都是这样子,现在来思考一下为什么这么做。
“领域层”的“领域服务”会依赖“仓储接口”,“仓储接口”也会依赖“聚合根”,这两者都是除了“实现依赖”之外的依赖关系,如果将“接口”放到“仓储实现”中就丧失了面向接口编程的意义(编译也不会通过),如果放到“独立层”中呢?会编译不通过,出现双向依赖了。
对于类似这种情况下接口,我们将其称为“SPI”,全程为:service provider interface,“SPI”的规则如下:
- 概念上更依赖调用方。
- 组织上位于调用方所在的包中。
- 实现位于独立的包中。
- 常见的例子是:插件模式的插件。
“接口”位于“实现方”所在的“包”中
我们先想象一个场景,以Unity提供的IUnityContainer接口为例,除了维护这个框架的团队之外,我们没有发现谁实现了这个接口,虽然理论上是可以实现这个接口的(如果能实现的话,我们何不自己弄额Ioc容器呢?)。
对于类似这种情况下的接口,我们将其称作为“API”,“API”的规则如下:
- 概念上更接近实现方。
- 组织上位于实现方所在的包中。
- 实现和接口在一个包中。
“接口”位于独立的“包”中
这里就不说场景了,如果一个“接口”在一个上下文是“API”,在另一个上下文是“SPI”,那么你就可以这么组织。
需要注意的事项
不管是SPI或API,接口都是可以组织到独立的“包”中,这么做是否有意义,自己来做出决定了。
SPI和API也不一定是接口,我这里都是指狭义的具体的接口。
另外一张图
备注
每一次思考都伴随着收获,也离不开和朋友们的交流,天更蓝了。
最新文章
- ios7 ios8 cell中下划线偏移(separator Insets)处理方法
- wpf arcgis engine 当前没有或未启用Spatial Analyst许可解决办法
- Fluent Nhibernate and Stored Procedures
- BZOJ1207 [HNOI2004]打鼹鼠
- style在进行图形绘制前,要设置好绘图的样式
- 学会简单使用poi进行excel有关操作
- C# 利用WORD模板和标签(bookmark) 批量生成WORD
- Eclipse,IDEA自动生成相应对象接收方法返回值的快捷键
- 怎样从官网下载Spring的jar包
- 第一百二十八节,JavaScript,Ajax
- OSG+Python
- Kmeans在MapReduce中的实现
- linux定时任务cron配置
- 吴恩达课后作业学习2-week1-3梯度校验
- POJ3076 Sudoku 舞蹈链 DLX
- 8 -- 深入使用Spring -- 5...2 使用@Cacheable执行缓存
- hdu-6194 string string string 后缀数组 出现恰好K次的串的数量
- vue / js使用video获取视频时长
- MVC3学习:Sql Server2005中时间类型DateTime的显示
- C#连接Oracle数据库的连接字符串