《基于模型的软件开发》——3.4 泛型

3.4 泛型

泛型是我们都在实际使用但却没有意识到自己在使用的一种方法。泛型通过参数化替代不同的行为。从本质上讲,我们所获得的不同结果,取决于单个行为职责的输入参数值——这种想法在“汇编宏”方法使用时就已经存在了,因此我们在此不多做讨论。实际上,它的另外一个名字——参数多态,表明它是多态的一种特例。
任何具有以下特征的方法都可以在技术上视为泛型的实例,在这些方法中,不同的行为依赖于该方法的参数值。因此,任何一个对参数值进行if判断的方法都可以视为泛型的实例。然而,大部分OO人员通常从存在显著行为差异这个方面考虑泛型。在这样的上下文中如何给“显著”一个很好的定义留给读者做练习。
由OO范式带来的一个特有的问题在于,如何扩展参数这一定义。以传统的视角看来,参数是过程的一个输入。在OO的上下文中,参数的定义扩展至包括任何潜在的状态变量,这些状态变量对于某一个行为方法是可访问的。因此在OO的上下文中,任何一个可达对象的任何知识属性都是行为职责中的一个潜在参数。
这引入了一种非常强大的设计模式,我们在一个对象中定义通用的行为职责,然后将该对象与另外一个对象进行关联,另外一个对象是“规格对象”,其属性参数是上述对象的通用行为。这使得我们可以在运行时动态地实例化对象之间的关系,即根据上下文动态确定哪一个“规格对象”是当前运行时“正确”的那一个。这是一种非常强大的技术,但是在当前的OO开发中没有得到充分的利用,我们将用整个第5章来论述这一技术。

时间: 2025-01-25 06:28:00

《基于模型的软件开发》——3.4 泛型的相关文章

《基于模型的软件开发》——导读

前言 软件开发是一项极其复杂的智力活动,它是一门朝气蓬勃并且仍在迅速发展的学科.软件开发还不够完善,因此迄今人们仍然在试图找出开发软件的好方法. 尽管如此,多年来软件开发方法仍然获得了大幅提升.许多设计方法学不断发展以促进软件设计的各个方面.其中之一是结构化设计方法,该方法提供了一种非常直观的方式,用以很好地匹配图灵和冯·诺依曼的硬件计算模型. 尽管结构化设计明显优于它之前的特定方法,但它存在着一个致命的弱点:当用户需求随着时间的推移改变时,软件往往很难随之修改,大型的应用尤其如此.与此同时,应

《基于模型的软件开发》——1.4 技术革新

1.4 技术革新 在OO范式之前,即使是编程的"黑暗时代",也并非一片混沌.学术界一直致力于调整数学运算使其能够应用于计算环境下的实践.经过认真思考,学术界提供了一种数学通用语言作为软件开发的基础.这是一个特别适用于计算环境的理论和模型集合.今天这些数学运算仍然是软件开发时一切工作的基础. 本书的重点为软件开发的工程方法,因此不会涉及很多理论.然而,主要的相关数学元素以及它们对软件开发的影响很值得用几个小节高屋建瓴地描述.因为这些理论现在仍然存在于OO范式背后,尽管是以一种非常隐秘的方

《基于模型的软件开发》——2.1 基本理念

2.1 基本理念 OO范式较之以前的软件开发方法更加复杂精密.从硬件计算的角度我们并没有直观感受,因此需要一种独特的思想.该范式也是由很多不同的.独立的概念整合而成.在这里我们将明确这些与第二部分和第三部分密切相关的基本概念.2.1.1 可维护性 在20世纪70年代,关于软件开发的实证研究很多,从中可以归纳出以下两个惊人的结论: 大部分软件公司70%的工作量用于维护. 用于修正现有特性的工作量是最初开发工作量用的5-10倍. 这中间显然存在问题.20世纪70年代后期这一现象演变成了软件危机,软件

《基于模型的软件开发》——2.2 广度优先处理(又称对等协作)

2.2 广度优先处理(又称对等协作) 第1章讨论了SD的深度优先,分层的功能分解以及与此相关的问题.这次同样是对象的问题.由于抽象.封装和逻辑不可分性,对象具有自包含实现,因此它们允许广度优先通信.这是因为你让对象做什么它就做什么,并能够完成,这完全依赖于它的逻辑不可分性和自包含性. 从客户角度看它是原子的,一个对象就是单个可标识的实体.因此,应用中重要的控制流是按照对象的交互(OO中的协作)进行描述的.这在一定程度上大大提高了控制流的抽象层次.事实上,在本书后面的章节中你将看到,当定义协作时,

《基于模型的软件开发》——1.3 宝贵教训

1.3 宝贵教训 当20世纪70年代末学术界开始对对象思想反思的时候,很多蹩脚的软件已经开发出来了,多到这些蹩脚软件中存在的通用模式已经非常明显了.很多论文和文档由此而来,例如1968年Dijkstra的经典文档:"Go To Statement Considered Harmful".这些模式代表了从软件开发中获得的惨痛教训(其中有一些是刚刚触及).1.3.1 全局数据持久状态变量用于记录系统的状态,当它们为全局可访问的时候经常会在意想不到的时间或者以意想不到的方式被修改,这是一个很

《基于模型的软件开发》——1.2 结构化开发

1.2 结构化开发 结构化开发无疑是20世纪80年代之前最重要的单个技术进步之一.它第一次为软件开发提供了真正意义上的系统化方法.与20世纪60年代的3GL结合,结构化开发能够使生产力取得重大进步.结构化开发具有一种很有趣的边界效益,这在当时未被注意到.应用更加可靠,当时人们没有留意这一点,因为软件应用得越来越广泛,对非软件的用户的可见性越来越高:软件依然存在很多缺陷,用户仍然认为软件是不可靠的.事实上,可靠性从20世纪60年代初的150个缺陷/千行降低到了20世纪80年代的15个缺陷/千行.结

《基于模型的软件开发》——第1部分 面向对象开发的根本

第1部分 面向对象开发的根本 基于模型的软件开发方法本质上是一种面向对象的方法.因此,为了充分了解这种方法,有必要大致理解面向对象的开发.由于面向对象的方法不如传统软件开发方法那样直观,因此我们需要理解面向对象方法的工作方式.本书这一部分着眼于面向对象方法诞生的历史背景,使我们能够了解传统方法存在的问题,也即面向对象的方法寻求解决的问题.

《基于模型的软件开发》——1.1 历史

1.1 历史 20世纪50年代基本上不存在系统化的开发,那是编程的"黑暗时代".现在的开发人员几乎很难想象当时的软件开发环境.当时大型主机的内存只有几KB(kilobyte,千字节),纸带就是高科技输入系统.西联曾经有效垄断了电传输入设备,该设备每按下一个键都需要做几英尺-磅的功,这些设备导致程序员患上腕管综合征,该症状甚至成了医学界的一个专有名词.没有浏览器.调试器或者CRT终端.基本汇编语言(Basic Assembly Language,BAL)是解决软件危机的银弹.20世纪50

《基于模型的软件开发》——第1章 历史的视角

第1章 历史的视角 问题是进步的代价.--Charles F.?Kettering和物理科学.工业革命相比,软件开发在人类发展史上相对较新.成为现代生活中无处不在的角色,物理科学花了一千多年.工业革命花了一个多世纪,而计算机和软件只花了30年不到的时间.当然,这中间走过的路是很艰辛的.本章提供了OO范式产生的历史背景.为了全面理解并评价这种范式,首先要了解它要解决的问题.因此我们从历史讲起,然后回顾一下在OO范式出现之前主流的软件开发方法存在的一些弱点,最后考察一些被OO范式采纳的重要技术进步,