“Follow the lead of hardware design! It is not right that every new development should start from scratch. There should be catalogs of software modules, as there are catalogs of VLSI devices: when we build a new system, we should be ordering components from these catalogs and combining them, rather than reinventing the wheel every time. We would write less software, and perhaps do a better job at that which we do get to write. Wouldn’t then some of the problems that everybody complains about — the high costs, the overruns, the lack of reliability — just go away? Why is it not so?”
"跟随着硬件设计的指引!每一轮新的开发都应该是从头开始的,这并不正确.应该总有软件模块的目录,如同VLSI(超大规模集成电路)装置的目录一样: 当我们建立一个新系统的时候,我们应该订购来自这些目录中的组件并且组合它们,而不是每一次都重新创建.我们应该尽量少写软件,在我们开始编码的时候也许能做一些更有意义的工作.不然随后每个人都抱怨的问题－高昂的费用,超出限度,缺乏可靠性－都会发生?为什么不这样做呢?”
You have probably heard remarks of this kind； perhaps you have uttered them yourself. As early as 1968, at the now famous NATO conference on software engineering, Doug McIlroy was advocating “mass-produced software components”. Reusability, as a dream, is not new.
您或许已经听到过这种评论；也许就是您自己说的.早在1968年,在那次著名的NATO(北大西洋公约组织)的软件工程会议上，Doug McIlroy就主张”大量生产软件组件(mass-produced software components)”.复用性,如同一个梦,早就存在了.
It would be absurd to deny that some reuse occurs in software development. In fact one of the most impressive developments in the industry since the first edition of this book was published in 1988 has been the gradual emergence of reusable components, often modest individually but regularly gaining ground； they range from small modules meant to work with Microsoft’s Visual Basic (VBX) and OLE 2 (OCX, now ActiveX) to full libraries, also known as “frameworks”, for object-oriented environments.
否认软件开发中的复用是荒谬的.事实上,自1988年本书第一个版本出版后,给人最深刻印象的(软件)工业发展之一是可复用的组件已经逐渐的出现,有时休答答的,却是有规率地发展着.它们的范围从与微软公司的Visual Basic(VBX)和OLE2(OCX,现在的ActiveX)一起工作的小模块,一直到面向对象环境中的完整的库,也即是"框架(frameworks)".
Another exciting development is the growth of the Internet: the advent of a wired society has eased or in some cases removed some of the logistic obstacles to reuse which, only a few years ago, might have appeared almost insurmountable.
另一个令人兴奋的发展是英特网的成长:连线社会的来到,已经减轻或去掉了在某种情况下的一些复用上的逻辑障碍,这在数年以前几乎是不能克服的问题.
But this is only a beginning. We are far from McIlroy’s vision of turning software development into a component-based industry. The techniques of object-oriented software construction make it possible for the first time to envision a state of the discipline, in the not too distant future, in which this vision will have become the reality, for the greatest benefit not just of software developers but, more importantly, of those who need their products — quickly, and at a high level of quality.
但是这只是开始.我们还离McIlroy's的构想很远,既将软件开发变成一个基于组件的工业.面向对象软件构造的技术让它第一次能够展望成一个产业的情形,在不远的将来中,这一个构想将会变成现实,分享最佳利益的不仅仅是软件开发者,更重要的,而是那些需要他们所够买的产品快速和高品质的人.
In this chapter we will explore some of the issues that must be addressed for reusability to succeed on such a large scale. The resulting concepts will guide the discussion of object-oriented techniques throughout the rest of this book.
在本章中,我们将会研究一些议题,对复用性在一个如此大范围上的成功性加以分析.所得之概念将会引导贯穿于本书中的面向对象技术的讨论.
4.1 THE GOALS OF REUSABILITY
4.1 复用性的目标
We should first understand why it is so important to improve software reusability. No need here for “motherhood and apple pie” arguments: as we will see, the most commonly touted benefits are not necessarily the most significant； by going beyond the obvious we can make sure that our quest for reuse will pursue the right targets, avoid mirages, and yield the highest return on our investment.
我们首先应该理解为什么改良软件的复用性是如此的重要.这里理所当然没有需求上的争论:如我们所见,通常最被吹捧的利益一定不是最有意义的；显而易见的是,我们能确定我们对复用的探索将追求着正确的目标,避免好高务远,而且在我们的投资方面能产生最高的回报.
Expected benefits
预期效益
From more reusable software you may expect improvements on the following fronts:
从更多的可复用软件中,您可能期待着在下列各项上的改进:
• Timeliness (in the sense defined in the discussion of software quality factors: speed of bringing projects to completion and products to market). By relying on existing components we have less software to develop and hence can build it faster.
时效性(在软件品质因数的讨论中已定义过: 项目完成和产品上市的速度). 通过使用现有的组件,我们的软件开发活动会变得更少并且因此构建会更快.
• Decreased maintenance effort. If someone else is responsible for the software, that someone is also responsible for its future evolutions. This avoids the competent developer’s paradox: the more you work, the more work you create for yourself as users of your products start asking you for new functionalities, ports to new platforms etc. (Other than relying on someone else to do the job, or retiring, the only solution to the competent software developer’s paradox is to become an incompetent developer so that no one is interested in your products any more — not a solution promoted by this book.)
减少维护的努力.如果其他人负责软件,那么此人也对将来的演化负有责任.这避免能者多劳的说法: 当使用产品的用户开始为了新的功能性或移植新平台对您有所要求的时候,您工作的越多,您也就有了越多的工作.(除了要求他人做此项工作,或者你退休,对能者多劳的说法而言,唯一的解决办法是要成为一个无能的开发者,以便没有人对您的产品再感兴趣－这可不是本书所要提出的解决办法)
• Reliability. By relying on components from a reputed source, you have the guarantee, or at least the expectation, that their authors will have applied all the required care, including extensive testing and other validation techniques； not to mention the expectation, in most cases, that many other application developers will have had the opportunity to try these components before you, and to come across any remaining bugs. The assumption here is not necessarily that the component developers are any smarter than you are； simply that the components they build — be they graphics modules, database interfaces, sorting algorithms ¼ — are their official assignment, whereas for you they might just be a necessary but secondary chore for the attainment of your official goal of building an application system in your own area of development.
可靠性.依赖于可靠的组件,您就有了保证,或至少可以预料,它们的作者已经处理了所有必需要考虑的情况,包括广泛的测试和其它的验证方法；在大部份的情形下,不要期待许多其他的应用程序开发者将会有机会在您之前使用这些组件,并遇到了其余的错误.这里不必假设组件开发者比您聪明多少；仅仅只是他们所构建的组件―图形模块,数据库接口,排序算法…—是他们的正式任务,但对您而言,要达到您的正式目标,既在您自己的开发领域中构建一个应用系统,它们可能是必须却次要的.
• Efficiency. The same factors that favor reusability incite the component developers to use the best possible algorithms and data structures known in their field of specialization, whereas in a large application project you can hardly expect to have an expert on board for every field touched on by the development. (Most people, when they think of the connection between reusability and efficiency, tend to see the reverse effect: the loss of fine-tuned optimizations that results from using general solutions. But this is a narrow view of efficiency: in a large project, you cannot realistically perform such optimizations on every piece of the development. You can, however, aim at the best possible solutions in your group’s areas of excellence, and for the rest rely on someone else’s expertise.)
高效性(效率).同样的支持复用性的因数,刺激了组件开发者使用最可能好的算法和在他们的专门领域中已知的数据结构,然而在一个大的应用项目中,您无法期待在开发中所涉及的每个领域都有一个专家.(当大多数的人考虑复用性和效率之间关系的时候,他们容易得到相反效果:使用通用的解决方案会导致调整的优化得以损失.但是这是一个效率上的狭隘观点:在一个大的项目中,您不可能在开发的每个阶段上都实际地完成这样的优化.然而,在您团队中最擅长的领域里,您能够把握最可能的解决方案,至于剩下的,依赖其他人的专长就可以了.)
• Consistency. There is no good library without a strict emphasis on regular, coherent design. If you start using such a library — in particular some of the best current object-oriented libraries — its style will start to influence, through a natural process of osmosis, the style of the software that you develop. This is a great boost to the quality of the software produced by an application group.
一致性．不能严格地强调规则和连贯的设计,就没有优秀的库.如果您开始使用这样的一个库－特别是一些当前最好的面向对象的库－经过自然的渗透作用,它的风格就会开始影响您所开发的软件风格.这极大的推进了应用程序团队所编写的软件品质.
• Investment. Making software reusable is a way to preserve the know-how and inventions of the best developers； to turn a fragile resource into a permanent asset.
投资. 软件复用是一种保护天才开发者的技术秘诀和发明创造的方法；这是将易碎的资源变成一个长久的资产.(这是一种聚沙成塔,聚腋成裘的投资)
Many people, when they accept reusability as desirable, think only of the first argument on this list, improving productivity. But it is not necessarily the most important contribution of a reuse-based software process. The reliability benefit, for example, is just as significant. It is extremely difficult to build guaranteeably reusable software if every new development must independently validate every single piece of a possibly huge construction. By relying on components produced, in each area, by the best experts around, we can at last hope to build systems that we trust, because instead of redoing what thousands have done before us — and, most likely, running again into the mistakes that they made — we will concentrate on enforcing the reliability of our truly new contributions.
当许多人认为值得接受复用性的时候,他们仅仅考虑了这个列表上的第一个讨论以提高生产力.但是它不是软件复用过程中最重要的贡献.比如说,可靠性的优点才是重要的.如果每一轮新的开发都必须独立地验证庞大的构造中每一个单元都是有效的,那么要建立一个真正的可复用软件是极端困难的.依赖现有的组件,在每个领域中有最好专家协助,我们最后希望能建立起可信赖的系统, 因为不再重新开发数以千计的之前已完成的工作－并且,最有可能再一次会遇到他们所造成的错误－我们将会专注于加强新系统的可靠性.
This argument does not just apply to reliability. The comment on efficiency was based on the same reasoning. In this respect we can see reusability as standing apart from the other quality factors studied in chapter 1: by enhancing it you have the potential of enhancing almost all of the other qualities. The reason is economic: if, instead of being developed for just one project, a software element has the potential of serving again and again for many projects, it becomes economically attractive to submit it to the best possible quality-enhancing techniques — such as formal verification, usually too demanding to be cost-effective for most projects but the most mission-critical ones, or extensive optimization, which in ordinary circumstances can often be dismissed as undue perfectionism. For reusable components, the reasoning changes dramatically； improve just one element, and thousands of developments may benefit.
这个讨论不仅仅适用于可靠性.在效率方面的评论也以相同的论证为基础.基于这种考虑,我们可以认为复用性不同于第1章中所学的其它品质因数:通过加强复用性,您可以潜在的提高几乎所有的其它品质.动机是经济上的: 如果不仅仅考虑只为一个项目所开发,一个软件元素可能多次为许多项目服务,把它作为最佳的提高品质的技术, 这会使项目变得更具经济性－例如说形式验证(formal verification),对大多数的项目来说通常过于苛刻并不划算,但却是最关键性任务,再说广泛最佳化(extensive optimization),在通常的情况下由于过于追求尽善尽美常常被叫停.对于可复用的组件,结论却戏剧性地发生变化；只需改善一个元素,数以千计的开发得以受益.
This reasoning is of course not completely new； it is in part the transposition to software of ideas that have fundamentally affected other disciplines when they turned from individual craftsmanship to mass-production industry. A VLSI chip is more expensive to build than a run-of-the-mill special-purpose circuit, but if well done it will show up in countless systems and benefit their quality because of all the design work that went into it once and for all.
这个结论当然不是全新的；它已经根本影响了那些从个人工艺转向到大规模生产工业的其他产业,这里部份转换到了软件理念上.一个超大规模集成电路(VLSI)芯片比一个普通的单一用途的电路制造更加昂贵,但是如果做得好的话, 因为一次设计到处运行的原因,它将会在无数的系统中出现并有利于提高它们的品质.
Reuse consumers, reuse producers
复用消费者,复用生产者
If you examined carefully the preceding list of arguments for reusability, you may have noted that it involves benefits of two kinds. The first four are benefits you will derive from basing your application developments on existing reusable components； the last one, from making your own software reusable. The next-to-last (consistency) is a little of both.
如果您仔细地检查前面的复用性讨论列表,您可能已经注意到它包括二种类型的优点.前四条的优点是您可以基于现有的可复用组件,构建您自己的应用程序；最后一条是可使您自己的软件复用.倒数第二条(一致性)涵盖了一些上述的优点.
This distinction reflects the two aspects of reusability: the consumer view, enjoyed by application developers who can rely on components； and the producer view, available to groups that build reusability into their own developments.
这种区别反映了复用性的二个方面: 消费者观点(consumer view),被依赖于组件的应用程序开发者所喜爱；生产者观点(producer view),有利于团队在他们自己的开发中建立复用性.
In discussing reusability and reusability policies you should always make sure which one of these two views you have in mind. In particular, if your organization is new to reuse, remember that it is essentially impossible to start as a reuse producer. One often meets managers who think they can make development reusable overnight, and decree that no development shall henceforth be specific. (Often the injunction is to start developing “business objects” capturing the company’s application expertise, and ignore general-purpose components — algorithms, data structures, graphics, windowing and the like — since they are considered too “low-level” to yield the real benefits of reuse.) This is absurd: developing reusable components is a challenging discipline； the only known way to learn is to start by using, studying and imitating good existing components. Such an approach will yield immediate benefits as your developments will take advantage of these components, and it will start you, should you persist in your decision to become a producer too, on the right learning path.
在探讨复用性和复用性策略的过程中,您总是需要确认两者之中您所关心的是那一个.特别地,如果您的组织对复用并不熟悉,要牢记从一个复用的生产者开始是根本不可能的.时常会遇见这样的管理人员,认为在一个晚上就能使软件开发变得可复用,因此断定自此以后没有什么开发情况需要特别计划.(通常命令是依照公司的应用程序专家们的建议,开始开发"业务对象",而忽略通用型的组件－算法,数据结构,图形,窗囗和类似的东西－因为这些是被认为是低层次的东西,不能得到真正的复用的利益.) 这是荒谬的:开发可复用的组件是一种挑战性的训练；唯一已知的学习方法就是要通过使用,学习和模仿优秀的现有组件来开始的.要是您的开发将会利用这些组件,这样的方式将会产生即得利益,并且,如果您坚持您的决定,它也将会使您在正确的学习道路上成为一位生产者.
|
Reuse Path principle Be a reuse consumer before you try to be a reuse producer. 在你试图成为一个复用的生产者之前,成为一个复用的消费者. |
4.2 WHAT SHOULD WE REUSE?
4.2 我们应该复用什么?
Convincing ourselves that Reusability Is Good was the easy part (although we needed to clarify what is really good about it). Now for the real challenge: how in the world are we going to get it?
让自己相信复用性有益这很容易(虽然我们需要阐明真正好在什么地方).现在,真正的挑战是: 我们究竟如何才能得到它?
The first question to ask is what exactly we should expect to reuse among the various levels that have been proposed and applied: reuse of personnel, of specifications, of designs, of “patterns”, of source code, of specified components, of abstracted modules.
第一个要问的问题是:在计划和实施的各种不同的层次之中,什么是我们应该真正期待的复用:人事的,规格的,设计的,"模式"的,源码的,规定组件的,还是抽象模块的.
Reuse of personnel
人事的复用
The most common source of reusability is the developers themselves. This form of reuse is widely practiced in the industry: by transferring software engineers from project to project, companies avoid losing know-how and ensure that previous experience benefits new developments.
最通常的复用性的来源是开发者自己.复用这一种形式在产业中被广泛的实现:通过让软件工程师在项目之间流动,公司避免了技术损失并且确保了新的开发利用先前的经验.
This non-technical approach to reusability is obviously limited in scope, if only because of the high turnover in the software profession.
如果只因为软件职业的高度流动性,那么这种非技术上的复用性方法明显地被限制在一定范围之内.
Reuse of designs and specifications
设计和规格的复用
Occasionally you will encounter the argument that we should be reusing designs rather than actual software. The idea is that an organization should accumulate a repository of blueprints describing accepted design structures for the most common applications it develops. For example, a company that produces aircraft guidance systems will have a set of model designs summarizing its experience in this area； such documents describe module templates rather than actual modules.
有时候您会遇到应该复用设计而并非复用实际的软件的争论.这种想法是一个组织应该累积设计的知识,为它所开发的绝大多数通用应用程序描述公认的设计结构.举例来说,一家生产飞机引导系统的公司将会有一系列的模型设计来概述他在这个领域的经验；这样的文件描述了模块模板而并非真实的模块.
This approach is essentially a more organized version of the previous one — reuse of know-how and experience. As the discussion of documentation has already suggested, the very notion of a design as an independent software product, having its own life separate from that of the corresponding implementation, seems dubious, since it is hard to guarantee that the design and the implementation will remain compatible throughout the evolution of a software system. So if you only reuse the design you run the risk of reusing incorrect or obsolete elements.
这种方式本质上是一个先前的更加组织化的版本－技术和经验的复用.在文档编写的讨论时已经建议了,作为一种独立的软件产品,其真正的设计概念有着自己的生命周期,这与对应的实现阶段相分离,看上去似乎有些疑惑,这是由于在整个软件系统的演化中,很难保证设计和实现会保持一致.所以如果您只复用设计,您将冒着复用了错误的或废弃的元素之危险.
These comments are also applicable to a related form of reuse: reuse of specifications.
这些解释也应用在一个相关形式的复用中: 规格的复用。
To a certain extent, one can view the progress of reusability in recent years, aided by progress in the spread of object technology and aiding it in return, as resulting in part from the downfall of the old idea, long popular in software engineering circles, that the only reuse worthy of interest is reuse of design and specification. A narrow form of that idea was the most effective obstacle to progress, since it meant that all attempts to build actual components could be dismissed as only addressing trivial needs and not touching the truly difficult aspects. It used to be the dominant view； then a combination of theoretical arguments (the arguments of object technology) and practical achievements (the appearance of successful reusable components) essentially managed to defeat it.
在一定程度上,可以把近几年来复用性的发展看做为旧观念衰落的部份结果,对象技术发展的进程帮助了复用性的发展,同时复用性作为回报也帮助了对象技术.而在软件工程领域长期流行的旧观念认为复用影响的重要性只是在设计和规格复用上.此观念的狭隘行为最大限度地阻碍了发展,由于这意谓要建立真正的组件的所有尝试都可能被叫停,因为这只是着重于琐细的需求,没有触及实际的困难方面.它过去一直是主流的观点；随后一个理论上的论据(对象技术的论据)和实际上的成就(成功的可复用组件的出现)的结合从根本上颠覆了它.
“Defeat” is perhaps too strong a term because, as often happens in such disputes, the result takes a little from both sides. The idea of reusing designs becomes much more interesting with an approach (such as the view of object technology developed in this book) which removes much of the gap between design and implementation. Then the difference between a module and a design for a module is one of degree, not of nature: a module design is simply a module of which some parts are not fully implemented； and a fully implemented module can also serve, thanks to abstraction tools, as a module design.With this approach the distinction between reusing modules (as discussed below) and reusing designs tends to fade away.
"颠覆"也许语气太重了,通常在这样的争论之中其结果需要平衡两边.复用设计的观念变得对消除设计和实现之间的许多差距的方法(这样的对象技术的观念会在本书中逐步展开)更加关注.那么在一个模块本身和一个模块设计之间的不同是一个程度,而不是本质:一个模块设计只不过是一个部份不能完全实现的简单模块；而借助于抽象工具,一个完整的实现模块也能看作是一个模块设计.借此方式,在复用模块(如下讨论)和复用设计之间的差别也逐渐淡化.
Design patterns
设计模式
In the mid-nineteen-nineties the idea of design patterns started to attract considerable attention in object-oriented circles. Design patterns are architectural ideas applicable across a broad range of application domains； each pattern makes it possible to build a solution to a certain design issue.
在二十世纪九十年代中叶,设计模式的思想在面向对象领域吸引了相当多的注意.设计模式是建筑上的观念,可广范的适用于应用领域；每个模式尽可能的对一个特定的设计议题建立一个解决方案.
Here is a typical example, discussed in detail in a later chapter. The issue: how to provide an interactive system with a mechanism enabling its users to undo a previously executed command if they decide it was not appropriate, and to reexecute an undone command if they change their mind again. The pattern: use a class COMMAND with a precise structure (which we will study) and an associated “history list”. We will encounter many other design patterns.
这儿有一个典型的例子,在稍后的章节中详细讨论.议题:如果其用户觉得一个先前运行的命令并不恰当,能让他们取消此命令,并且如果他们再一次改变他们的想法的话,能让他们重新运行一个未完成的指令,那么该如何提供一个机制给这个交互式系统.模式: 使用具有精确的结构(我们将会学习到)的类COMMAND和一个关联的"历史记录列表".我们还会遇到许多其它的设计模式.
One of the reasons for the success of the design pattern idea is that it was more than an idea: the book that introduced the concept, and others that have followed, came with a catalog of directly applicable patterns which readers could learn and apply.
设计模式思想的成功理由之一是它不只是一个思想: 介绍概念的著作,和其它的后续作品,一起提供了完全应用模式的目录,读者可以学习并且运用它们.
Design patterns have already made an important contribution to the development of object technology, and as new ones continue to be published they will help developers to benefit from the experience of their elders and peers. How can the general idea contribute to reuse? Design patterns should not encourage a throwback to the “all that counts is design reuse” attitude mentioned earlier. A pattern that is only a book pattern, however elegant and general, is a pedagogical tool, not a reuse tool； after all, computing science students have for three decades been learning from their textbooks about relational query optimization, Gouraud shading, AVL trees, Hoare’s Quicksort and Dijkstra’s shortest path algorithm without anyone claiming that these techniques were breakthroughs in reusability. In a sense, the patterns developed in the past few years are only incremental additions to the software professional’s bag of standard tricks. In this view the new contribution is the patterns themselves, not the idea of pattern.
设计模式已经对对象技术的发展作出了重要的贡献,而且当新的模式出版后,它们会帮助开发者受益于他们的长辈和同辈的经验.这样的思想如何帮助复用? 设计模式不会鼓励倒退到早期所宣扬的态度,即"所有皆设计成复用".如果只是书本上的一个模式,虽然优雅而且通用,却是一个教学的工具,而不是一个复用的工具；毕竟,计算科学的学生们已经从他们的教科书上学习了有关关联查询最佳化,高洛德着色,AVL树,Hoare的快速排序和Dijkstra的最短路径算法长达三十年之久,没有任何人宣称这些技术在复用性上的突破.在某种意义上,在过去数年内模式的发展只是增加了软件专业人士的智囊.在这个观点中新的贡献是模式自己,而不是模式的思想.
[注]Gouraud Shading：用三角形顶点的颜色来进行插值得到三角形内部每个点颜色
As most people who have looked carefully at the pattern work have recognized, such a view is too limited. There seems to be in the very notion of pattern a truly new contribution, even if it has not been fully understood yet. To go beyond their mere pedagogical value, patterns must go further. A successful pattern cannot just be a book description: it must be a software component, or a set of components. This goal may seem remote at first because many of the patterns are so general and abstract as to seem impossible to capture in actual software modules； but here the object-oriented method provides a radical contribution. Unlike earlier approaches, it will enable us to build reusable modules that still have replaceable, not completely frozen elements: modules that serve as general schemes (patterns is indeed the appropriate word) and can be adapted to various specific situations. This is the notion of behavior class (a more picturesque term is programs with holes)； it is based on O-O techniques that we will study in later chapters, in particular the notion of deferred class. Combine this with the idea of groups of components intended to work together — often known as frameworks or more simply as libraries — and you get a remarkable way of reconciling reusability with adaptability. These techniques hold, for the pattern movement, the promise of exerting, beyond the new-bag-of-important-tricks effect, an in-depth influence on reusability practices.
大多数在仔细研究模式工作的人已经认识到,这样的一个观点太有局限性.在模式的真正观念里面似乎形成了一个真实的新贡献,即使它仍然没有被完全地了解.为了要超越它们纯粹的教学价值,模式一定要更进一步.一个成功的模式不能够仅仅是书本上的描述:它一定是一个软件组件,或一个组件组. 因为许多模式过于通用和抽象,似乎不太可能在真正的软件模块中得到,所以这一个目标起先看上去有些遥不可及；但在这里,面向对象的方法提供一个根本的帮助.不同于早期的方法,它将使我们能够构建可复用的模块,这些模块是可替换的,并没完全地固定其元素:模块可以适用于通用方案(模式的确是适当的单词),也能适应各种不同的特定情形.这是行为类(Behavior Class)的概念(一个较生动的术语是有洞的程序(programs with holes))；它是基于将会在后面的章节中学习到的OO技术之上,特别是延期类的观念.把它和组件组的思想结合起来共同工作－即是框架或更简单的称为库－同时您能获得适应性和复用性相一致的显著方法.为了模式发展,这些技术在复用性实践上产生着深入的影响,并超过了新智囊的效果.
Reusability through the source code
源代码的复用性
Personnel, design and specification forms of reuse, useful as they may be, ignore a key goal of reusability. If we are to come up with the software equivalent of the reusable parts of older engineering disciplines, what we need to reuse is the actual stuff of which our products are made: executable software. None of the targets of reuse seen so far — people, designs, specifications — can qualify as the off-the-shelf components ready to be included in a new software product under development.
人事,设计和规格复用的形式,它们本身是有用的,但却忽略一个复用性的关键目标.如果我们要去发觉在以前的工程产业中相关于软件的可复用部份的话,那么我们所需要复用的正是制造我们产品的原料:执行软件. 迄今为止,没有一个复用的目标－人,设计,规格－能够有资格作为现成的组件包含在所开发的新软件产品中.
If what we need to reuse is software, in what form should we reuse it? The most natural answer is to use the software in its original form: source text. This approach has worked very well in some cases. Much of the Unix culture, for example, originally spread in universities and laboratories thanks to the on-line availability of the source code, enabling users to study, imitate and extend the system. This is also true of the Lisp world.
如果我们需要复用的是软件,我们应该复用它的什么形式? 最自然的回答是使用软件的最初形式: 源代码. 这种方式已经在一些情况中工作得很好.举例来说，许多的Unix系统的培养,最初都在大学和实验室里传播,这是因为可以在线使用源代码,使得用户能够学习,模仿并且扩充系统.Lisp领域也是一样的.
The economic and psychological impediments to source code dissemination limit the effect that this form of reuse can have in more traditional industrial environments. But a more serious limitation comes from two technical obstacles:
对于源代码的发布,经济和心理上的障碍限制了这种复用形式在更传统的工业环境中的实施.但是更严重的限制来自二种技术上的障碍:
• Identifying reusable software with reusable source removes information hiding. Yet no large-scale reuse is possible without a systematic effort to protect reusers from having to know the myriad details of reused elements.
把可复用的软件理解成去除了信息隐藏的可复用的源代码.如果没有一个系统性的帮助,让复用者不必了解复用元素的种种细节,那么大规模的复用是仍然不可能的.
• Developers of software distributed in source form may be tempted to violate modularity rules. Some parts may depend on others in a non-obvious way, violating the careful limitations which the discussion of modularity in the previous chapter imposed on inter-module communication. This often makes it difficult to reuse some elements of a complex system without having to reuse everything else.
分发源代码的软件开发者可能试图违反模块性规则.其中一些部份以一种隐含的方式依赖于其它的部分,这违犯了潜在的限制,这是在先前章节的模块性讨论中所强调的模块间通信.在不复用其它部分的情况下,这时常会使复用一个复杂系统中的一些元素变得困难.
A satisfactory form of reuse must remove these obstacles by supporting abstraction and providing a finer grain of reuse.
一个适当的复用形式必须通过支持抽象化并提供更好的少量复用来消除这些障碍.
Reuse of abstracted modules
抽象模块的复用
All the preceding approaches, although of limited applicability, highlight important aspects of the reusability problem:
虽然只是有限地适用,但所有上述的方法都强调了复用性问题的重要方面:
• Personnel reusability is necessary if not sufficient. The best reusable components are useless without well-trained developers, who have acquired sufficient experience to recognize a situation in which existing components may provide help.
人事复用性是必需的,否则并不充份.如果没有训练有素的开发者,其已经有充份的经验认识到哪一种情形下哪一种已存在的组件可以提供帮助,那么最好的复用组件也都是无用的.
• Design reusability emphasizes the need for reusable components to be of sufficiently high conceptual level and generality — not just ready-made solutions to special problems. The classes which we will encounter in object technology may be viewed as design modules as well as implementation modules.
设计复用性强调了对可复用组件的需要只是一种足够高的概念层次和通论－对特别的问题没有现成的解决办法.我们将在对象技术方面遇到的一些类可以看作是设计模块和实现模块.
• Source code reusability serves as a reminder that software is in the end defined by program texts. A successful reusability policy must produce reusable program elements.
源代码复用性暗示了软件是程序本文的最终定义.一个成功的复用性政策一定能产生出可复用的程序元素.
The discussion of source code reusability also helps narrow down our search for the proper units of reuse. A basic reusable component should be a software element. (From there we can of course go to collections of software elements.) That element should be a module of reasonable size, satisfying the modularity requirements of the previous chapter； in particular, its relations to other software, if any, should be severely limited to facilitate independent reuse. The information describing the module’s capabilities, and serving as primary documentation for reusers or prospective reusers, should be abstract: rather than describing all the details of the module (as with source code), it should, in accordance with the principle of Information Hiding, highlight the properties relevant to clients.
源代码复用性的讨论也帮助我们缩小了搜寻适当的复用单元的范围.一个基本的可复用组件应该是一个软件元素.(当然从那里我们能定位到软件元素的集合.) 那个元素应该是一个合理大小的模块,满足先前章节所说的模块化需求；特别地,和其它软件的关系应该被严格地限制,使其有利于独立复用.描述模块能力的信息,和服务于复用者或准复用者的主要文档,应该是抽象的: 胜于描述模块(或源代码)的所有细节,它应该符合信息隐藏的原则,强调与客户端相关的属性.
The term abstracted module will serve as a name for such units of reuse, consisting of directly usable software, available to the outside world through a description which contains only a subset of each unit’s properties.
术语抽象模块(abstracted module)用于这样的复用单元的名字,即由直接地可用之软件组成,经过只包含每个单元特性的一个子集的描述,对外部的系统有效.
The rest of part B of this book is devoted to devising the precise form of such abstracted modules； part C will then explore their properties.
本书余下的B部份会专注于设计这样的抽象模块的精确形式；然后,C部份将会研究它们的属性.
The emphasis on abstraction, and the rejection of source code as the vehicle for reuse, do not necessarily prohibit distributing modules in source form. The contradiction is only apparent: what is at stake in the present discussion is not how we will deliver modules to their reusers, but what they will use as the primary source of information about them. It may be acceptable for a module to be distributed in source form but reused on the basis of an abstract interface description.
着重于抽象化,并拒绝源代码作为复用的载体,这不必禁止源代码形式的分布式模块. 矛盾只是表面的: 在目前讨论中危险的不是我们将如何发送模块给它们的复用者,而是他们将使用模块作为主要的的信息资源.以源代码的形式分发但以一个抽象接口描述为基础复用,对一个模块来说这是可接受的。
4.3 REPETITION IN SOFTWARE DEVELOPMENT
4.3 软件开发中的重复
To progress in our search for the ideal abstracted module, we should take a closer look at the nature of software construction, to understand what in software is most subject to reuse.
在我们研究理想的抽象模块的进程中,我们应该更加关注软件构造的本质,理解在软件中什么是最需要复用的.
Anyone who observes software development cannot but be impressed by its repetitive nature. Over and again, programmers weave a number of basic patterns: sorting, searching, reading, writing, comparing, traversing, allocating, synchronizing¼
Experienced developers know this feeling of déjà vu, so characteristic of their trade.
观察软件开发的任何人都必然对它的重复性质留下深刻的印象.程序员们反复地编排着大量的基本模式:排序,查找,读,写,比较,遍历,分配,同步… 富有经验的开发者了解déjà vu的感觉,这在他们的职业中非常的典型.
[注]: déjà vu 是一个强大的,自定义的CAT(Computer Aided Translation)系统.
A good way to assess this situation (assuming you develop software, or direct people who do) is to answer the following question:
|
How many times over the past six months did you, or people working for you, write some program fragment for table searching? 在过去六个月以来,您或您的手下,为表查询写了多少段程序?
|
要评估这种情形(假定您开发软件,或指挥开发之人)的一个好方法是回答下列的问题:
Table searching is defined here as the problem of finding out whether a certain element x appears in a table t of similar elements. The problem has many variants, depending on the element types, the data structure representation for t, the choice of searching algorithm.
在这里表查询被定义为:找出一个指定的元素x是否在表t中出现的问题.问题有许多种变体,这依赖于元素类型, t的数据结构表示法,或查询算法的选择.
Chances are you or your colleagues will indeed have tackled this problem one or more times. But what is truly remarkable is that — if you are like others in the profession — the program fragment handling the search operation will have been written at the lowest reasonable level of abstraction: by writing code in some programming language, rather than calling existing routines.
碰巧的是您或您的同事的确已经处理了这个问题一至多次.但是真正有意义的是－如果您就象同行中的其他人一样－处理查询操作的程序段已经在极不合理的抽象化层次中完成的:用程序语言来编写代码,而不是调用已存在的例程.
To an observer from outside our field, however, table searching would seem an obvious target for widely available reusable components. It is one of the most researched areas of computing science, the subject of hundreds of articles, and many books starting with volume 3 of Knuth’s famous treatise. The undergraduate curriculum of all computing science departments covers the most important algorithms and data structures. Certainly not a mysterious topic. In addition:
然而,对来自我们的领域之外的一位观察者而言,对于广泛适用的复用组件来说,表查询就象是一个明显的目标.它是计算机科学中研究最多的领域之一,数以百计文章的主题和书都源于Knuth's的著名论文的第3册.所有计算机科学系的大学课程中都包括了最重要的算法和数据结构.这当然并不是一个神秘的主题. 除此之外:
[注]: <<The Art of Computer Porgramming, Volume 3 – Sorting and Searchng Second Edition>>
• It is hardly possible, as noted, to write a useful software system which does not include one or (usually) several cases of table searching. The investment needed to produce reusable modules is not hard to justify.
如记录所示,几乎不可能编写出一个有效的软件系统却不包括一个或(通常)几个表查询的情况.产生可复用模块的投资收益是不难证明的.
• As will be seen in more detail below, most searching algorithms follow a common pattern, providing what would seem to be an ideal basis for a reusable solution.
您会看到下面更多的细节,大部分的查询算法遵循着一个通用的模式,提供了一个可复用的解决方案的理想基础.
2837
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
