返回介绍

5.4 方向 2:程序组织的结构化(从模块化到产品化)

发布于 2024-12-15 23:01:45 字数 3115 浏览 0 评论 0 收藏 0

问题 3:语法与语义上的特性,是否决定了该语言可能适宜的开发规模?

在第三个问题上的尝试,推动了结构化思想在另一方向上的发展 9 ,即通过在 程序组织 上的结构化来 解决规模问题 。这一方向上的主要动力,是程序所应对的需求渐渐扩展到非专业领域,用户的入口变得多样,甚至同一功能涉及到多种用户/角色的、不同时间与时序上的参与。这些也是软件开发工作的成果从专属程序进化到软件产品的主要标志。

我所观察到的第一个与此相关的语法元素是单元(unit) 10 。因为一段代码可以写得任意长,也可以拆成几个单元,所以这些单元存在与否,就与这段代码要表达的计算功能是完全无关的了——既不是对运算的增强,也不是对数据的增强。接下来,我们发现一些单元可以对许多不同的 function/program 的开发提供支持,由此库(library)的概念就形成了。“库”用于集中管理一些具有相同应用范围、处理相关数据、解决相似问题的单元以及单元对外部声明的界面(interface)。如图 4 所示,这些语法元素之间的关系非常简单。

图 4 单元、库与界面间的关系

大多数情况下,库与库之间的区别仅在于功能集不同、应用范围不同、接口方式不同,以及我们经常关注的效率等的不同。(不考虑这些外在的表现)这些库内在的抽象思想与应用价值是完全相当的。

库的出现带来了一些组织程序的策略,例如静态链接库(Lib,Static Link Library)、动态链接库(DLL,Dynamic Link Library)、类库(Class Library);又例如跨语言的组件库(COM 库、Component 或 Component Library)、公共程序集(Common Assembely);再例如,远程/跨平台对象(Remoting Object,或 XPCOM)等。这些策略被种种语言实现为不同的、语言内置的关键字,并由此决定了各自不同的一套支持语法。

所有这一切的目的,仅仅是因为那个最原始的发现:总有一些代码与当前处理的业务没有实际关系,可以被隔离到其他代码块(例如 Unit)中去。既然从组织策略来看这种隔离必然会发生,那么我们关注的问题就仅仅是上图的 Library 对外表达的形式(亦即是接口/Interface),而非 Unit 或类似语法元素的实际实现 11

这些变化既有语言进化的内在动力,也有软件规模变化这一外因的推动。当计算机不再仅是用于计算的工具,而变成软件产品的运行平台时,整个软件——传统意义上的程序(program)——的构成已经发生了明显的变化。现在,它必须面临的问题包括三个方面,如图 5 所示。

图 5 面临的问题与背景:Application 在“结构化”上选择不同方向的原因

也就是说,即使程序——我们仍然可以用第二个等级中的“程序”(program)来指代上图中的一个方面——在功能上的规模没有任何变化,那么也将面临如下两类需求:

  • 使用人群由专业人员变成普通用户,将导致提出大量的 非功能需求 ,即它作为“软件”的使用问题;
  • 由于使用人群的变化,维护和发布的工作对程序员变得不可控,因此将导致提出大量的 非当前需求 ,即它作为“产品”的生命周期问题。

这二者,也即是“软件产品”之于“程序、功能”的区别。举例来说,在最初的操作系统中,我们开出一个内存块来使用。

  • 首先,我们仅仅是需要在别的计算过程中使用到它,因此它被实现为一个功能(function) 12
  • 接下来,操作计算机的专业人士认为,其实可以从内存中拿出一块来并将它 mount 成一个虚拟的磁盘,于是将它写成了一个“简单的”程序(program) 13
  • 之后,某个并不太懂计算机的桌面用户也需要上述功能,但受限于他的计算机操作水平、实际的应用环境 14 ,他必然会在上述程序、功能之外,提出前述两类需求。

对于这类(软件产品的)用户,我们称支持非功能需求与非当前需求的程序为 应用(application) ,而将这一等级上的语言统称为 “应用程序设计语言”(application programming language) 。这些需求促使一个应用中包括了多个领域的产品功能,一些显而易见的内容包括:

  • 与产品使用相关的界面,例如 3D 操作、游戏界面、数字监控仪表盘等;
  • 与应用环境相关的业务逻辑规则,例如企业组织架构、工作流、金融、期货等;
  • 与操作平台相关的开发接口,例如 ATL、Android SDK、GTK+等;
  • 与发布、维护相关的支持,例如帮助文档、安装包、工程文件管理、代码文档化等;
  • ……

这些内容的领域性特点使得任何一个或一类程序员都无法完全胜任它们的开发工作。单元等类似手段以及模块划分时需要隐藏内部信息的思想,都是在这样的背景下产生的。其产生的必然性,是 泛计算领域15 本身的纵向隔离的特性所决定的 16 。也就是说,既然这是软件需求从专业计算领域走向泛计算领域带来的规模问题,那么也要求程序在组织上的抽象必须能表达和匹配后者在领域问题上的纵向切分。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文