- 内容提要
- 序 1:程序里的世界
- 序 2:最后一层表象
- 关于本书
- 致谢
- 引言:简单的本源
- 篇一:计算系统
- 第 1 章 数,以及对数据的性质的思考
- 第 2 章 逻辑
- 第 3 章 抽象
- 篇二:语言及其面临的系统
- 第 4 章 语言
- 第 5 章 从功能到系统
- 篇三:程序设计的核心思想
- 第 6 章 数据结构:顺序存储
- 第 7 章 数据结构:散列存储
- 第 8 章 执行体与它在执行过程中的环境
- 第 9 章 语法树及其执行过程
- 第 10 章 对象系统:表达、使用与模式
- 篇四:应用开发基础
- 第 11 章 应用开发的背景与成因
- 第 12 章 应用开发技术
- 第 13 章 开发视角下的工程问题
- 第 14 章 应用程序设计语言的复杂性
- 篇五:系统的基础部件
- 第 15 章 分布
- 第 16 章 依赖
- 第 17 章 消息
- 第 18 章 系统
- 篇六:系统的基本组织方法与原理
- 第 19 章 行为的组织及其抽象
- 第 20 章 领域间的组织
- 附一:主要编程范式 及其语言特性关系
- 附二:继承与混合,略谈系统的构建方式
- 附三:像大师们一样思考——从 UML 何时死掉 谈起
- 附四:VCL 已死,RAD 已死
文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
19.3 服务与结点:一组接口 在两种视角下的抽象概念
系统由领域组成,领域又由细分领域组成……由此我们最终所讨论的、具体的、作为组成部件的领域被表达为:
- 包含了特定领域知识,
- 提供了基于上述知识的处理能力,
- 反馈了在领域间可理解信息的一组行为。
对于这样一组行为,我们称之为“(该子系统/领域的)接口”。请注意,我们讨论系统中的接口时,它是脱离具体语言的。我们需要这样一层抽象概念的根本原因在于:
- 将领域问题转义为一组逻辑的界面;
- 将领域间有无关系,转义为“领域对领域(调用者与被调用者)”的接口是否可达;
- 屏蔽领域内的数据性质 5 ,迫使开发者必须通过特定的设计来解决领域间的数据问题(例如数据类型、数据依赖等)。
在这三种原因(或可称为三类需求及其解决手段)中,第一种和第二种是显性的,它们由接口的抽象特性决定:其一,表达为一组方法;其二,能否使用这些方法,取决于能否获得接口。
第三种则是隐性的,并且也是决定系统稳定性的最主要因素。事实上在这样的背景之下,开发者能够选择的方案也相对有限,主要包括远程方法或远程对象、消息/状态、序列化、分布等。
最终,我们将提供一组接口的系统组成构件称为一个“服务”,或一个“结点”。前者是功能视角下的一个概念,后者则基于部署视角 6 。但总的来说,服务/结点都意味“非本地”的支持,这也可以理解为对“跨领域的需求”的支持。
- 事实上,业界现在又把这两个学术化的领域统一称为“云”,包括云计算、云存储等具体的解决方案。关于数据或运算的规模也存在许多其他细分的领域和混杂的概念,例如早期的网格(Grid)与现在的大数据(Big Data)。无论如何,这些都只是分布问题在业界的具体表现而已。 ↩
- 就目前来说,通用应用开发语言主要是指面向对象语言或结构化程序设计语言,例如 Java、C#,以及 C 语言等。 ↩
- 因此,在缺乏这样的需求——例如在一个小一些的、跨领域特性并不突出——的系统或应用中,要求实施“面向接口设计”是一件相当多余而又学术化的事情。 ↩
- 另外,我们也可能通过静态数据与增量数据、本地数据与远程数据等分类法来区别不同的数据。我在这里采用“结构化”这一分类法只是一种选择,仅为了说明常见的问题,而非一个强制设定。 ↩
- 这涉及数据的全部三种性质:标识、值与确定性,以及由确定性带来的分布、状态等性质。 ↩
- 两者除了抽象视角的不同,在实现上通常也有差异(这里的服务与结点主要分别基于 Java 和 Erlang 中的概念)。 ↩
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论