“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.
您會看到下面更多的細節,大部分的查詢算法遵循着一個通用的模式,提供了一個可複用的解決方案的理想基礎.