面向?qū)ο蟪绦蛟O(shè)計外文翻譯2

1、<p>　　附 錄1. 外文文獻</p><p>　　Introduction To Objects</p><p>　　1、The progress of abstraction</p><p>　　All programming languages provide abstractions. It can be argued that the com

2、plexity of the problems you’re able to solve is directly related to the kind and quality of abstraction. By “kind” I mean, “What is it that you are abstracting?” Assembly language is a small abstraction of the underlying

3、 machine. Many so-called “imperative” languages that followed (such as FORTRAN, BASIC, and C) were abstractions of assembly language. These languages are big improvements over assembly language, but thei</p><p

4、>　　The alternative to modeling the machine is to model the problem you’re trying to solve. Early languages such as LISP and APL chose particular views of the world (“All problems are ultimately lists” or “All problems

5、 are algorithmic,” respectively). PROLOG casts all problems into chains of decisions. Languages have been created for constraint-based programming and for programming exclusively by manipulating graphical symbols. (The l

6、atter proved to be too restrictive.) Each of these approaches is a</p><p>　　The object-oriented approach goes a step further by providing tools for the programmer to represent elements in the problem space.

7、This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as “objects.”

8、(You will also need other objects that don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the</p><p>　　Alan Kay summarized five basic characteristics o

9、f Smalltalk, the first successful object-oriented language and one of the languages upon which Java is based. These characteristics represent a pure approach to object-oriented programming: </p><p>　　Everyth

10、ing is an object. Think of an object as a fancy variable; it stores data, but you can “make requests” to that object, asking it to perform operations on itself. In theory, you can take any conceptual component in the pro

11、blem you’re trying to solve (dogs, buildings, services, etc.) and represent it as an object in your program. </p><p>　　A program is a bunch of objects telling each other what to do by sending messages. To ma

12、ke a request of an object, you “send a message” to that object. More concretely, you can think of a message as a request to call a method that belongs to a particular object. </p><p>　　Each object has its ow

13、n memory made up of other objects. Put another way, you create a new kind of object by making a package containing existing objects. Thus, you can build complexity into a program while hiding it behind the simplicity of

14、objects. </p><p>　　Every object has a type. Using the parlance, each object is an instance of a class, in which “class” is synonymous with “type.” The most important distinguishing characteristic of a class

15、is “What messages can you send to it?” </p><p>　　All objects of a particular type can receive the same messages. This is actually a loaded statement, as you will see later. Because an object of type “circle”

16、 is also an object of type “shape,” a circle is guaranteed to accept shape messages. This means you can write code that talks to shapes and automatically handle anything that fits the description of a shape. This substit

17、utability is one of the powerful concepts in OOP. </p><p>　　Booch offers an even more succinct description of an object:</p><p>　　An object has state, behavior and identity.</p><p>

18、　　This means that an object can have internal data (which gives it state), methods (to produce behavior), and each object can be uniquely distinguished from every other object—to put this in a concrete sense, each object

19、 has a unique address in memory.</p><p>　　2、 An object has an interface</p><p>　　Aristotle was probably the first to begin a careful study of the concept of type; he spoke of “the class of fishe

20、s and the class of birds.” The idea that all objects, while being unique, are also part of a class of objects that have characteristics and behaviors in common was used directly in the first object-oriented language, Sim

21、ula-67, with its fundamental keyword class that introduces a new type into a program. </p><p>　　Simula, as its name implies, was created for developing simulations such as the classic “bank teller problem.”

22、In this, you have a bunch of tellers, customers, accounts, transactions, and units of money—a lot of “objects.” Objects that are identical except for their state during a program’s execution are grouped together into “cl

23、asses of objects” and that’s where the keyword class came from. Creating abstract data types (classes) is a fundamental concept in object-oriented programming. Abstract </p><p>　　So, although what we really

24、do in object-oriented programming is create new data types, virtually all object-oriented programming languages use the “class” keyword. When you see the word “type” think “class” and vice versa.</p><p>　　Si

25、nce a class describes a set of objects that have identical characteristics (data elements) and behaviors (functionality), a class is really a data type because a floating point number, for example, also has a set of char

26、acteristics and behaviors. The difference is that a programmer defines a class to fit a problem rather than being forced to use an existing data type that was designed to represent a unit of storage in a machine. You ext

27、end the programming language by adding new data types spec</p><p>　　The object-oriented approach is not limited to building simulations. Whether or not you agree that any program is a simulation of the syste

28、m you’re designing, the use of OOP techniques can easily reduce a large set of problems to a simple solution. </p><p>　　Once a class is established, you can make as many objects of that class as you like, an

29、d then manipulate those objects as if they are the elements that exist in the problem you are trying to solve. Indeed, one of the challenges of object-oriented programming is to create a one-to-one mapping between the el

30、ements in the problem space and objects in the solution space. </p><p>　　But how do you get an object to do useful work for you? There must be a way to make a request of the object so that it will do somethi

31、ng, such as complete a transaction, draw something on the screen, or turn on a switch. And each object can satisfy only certain requests. The requests you can make of an object are defined by its interface, and the type

32、is what determines the interface. A simple example might be a representation of a light bulb: </p><p>　　Light lt = new Light();</p><p><b>　　lt.on();</b></p><p>　　The int

33、erface establishes what requests you can make for a particular object. However, there must be code somewhere to satisfy that request. This, along with the hidden data, comprises the implementation. From a procedural prog

34、ramming standpoint, it’s not that complicated. A type has a method associated with each possible request, and when you make a particular request to an object, that method is called. This process is usually summarized by

35、saying that you “send a message” (make a request) to </p><p>　　Here, the name of the type/class is Light, the name of this particular Light object is lt, and the requests that you can make of a Light object

36、are to turn it on, turn it off, make it brighter, or make it dimmer. You create a Light object by defining a “reference” (lt) for that object and calling new to request a new object of that type. To send a message to the

37、 object, you state the name of the object and connect it to the message request with a period (dot). From the standpoint of the user of </p><p>　　The preceding diagram follows the format of the Unified Model

38、ing Language (UML). Each class is represented by a box, with the type name in the top portion of the box, any data members that you care to describe in the middle portion of the box, and the methods (the functions that b

39、elong to this object, which receive any messages you send to that object) in the bottom portion of the box. Often, only the name of the class and the public methods are shown in UML design diagrams, so the middle portio&

40、lt;/p><p>　　3、 An object provides services. </p><p>　　While you’re trying to develop or understand a program design, one of the best ways to think about objects is as “service providers.” Your prog

41、ram itself will provide services to the user, and it will accomplish this by using the services offered by other objects. Your goal is to produce (or even better, locate in existing code libraries) a set of objects that

42、provide the ideal services to solve your problem. </p><p>　　A way to start doing this is to ask “if I could magically pull them out of a hat, what objects would solve my problem right away?” For example, sup

43、pose you are creating a bookkeeping program. You might imagine some objects that contain pre-defined bookkeeping input screens, another set of objects that perform bookkeeping calculations, and an object that handles pri

44、nting of checks and invoices on all different kinds of printers. Maybe some of these objects already exist, and for the ones that don</p><p>　　Thinking of an object as a service provider has an additional be

45、nefit: it helps to improve the cohesiveness of the object. High cohesion is a fundamental quality of software design: It means that the various aspects of a software component (such as an object, although this could also

46、 apply to a method or a library of objects) “fit together” well. One problem people have when designing objects is cramming too much functionality into one object. For example, in your check printing module, you may <

47、/p><p>　　Treating objects as service providers is a great simplifying tool, and it’s very useful not only during the design process, but also when someone else is trying to understand your code or reuse an obje

48、ct—if they can see the value of the object based on what service it provides, it makes it much easier to fit it into the design. </p><p>　　附 錄2. 中文翻譯</p><p><b>　　對象入門</b></p>

49、<p>　　1、抽象的進步 所有編程語言的最終目的都是提供一種“抽象”方法。一種較有爭議的說法是：解決問題的復雜程度直接取決于抽象的種類及質(zhì)量。這兒的“種類”是指準備對什么進行“抽象”？匯編語言是對基礎(chǔ)機器的少量抽象。后來的許多“命令式”語言（如FORTRAN，BASIC和C）是對匯編語言的一種抽象。與匯編語言相比，這些語言已有了長足的進步，但它們的抽象原理依然要求我們著重考慮計算機的結(jié)構(gòu)，而非考慮問題本身的結(jié)構(gòu)。在

50、機器模型（位于“方案空間”）與實際解決的問題模型（位于“問題空間”）之間，程序員必須建立起一種聯(lián)系。這個過程要求人們付出較大的精力，而且由于它脫離了編程語言本身的范圍，造成程序代碼很難編寫，而且要花較大的代價進行維護。由此造成的副作用便是一門完善的“編程方法”學科。 為機器建模的另一個方法是為要解決的問題制作模型。對一些早期語言來說，如LISP和APL，它們的做法是“從不同的角度觀察世界”——“所有問題都歸納為列表”或“所有問題

51、都歸納為算法”。PROLOG則將所有問題都歸納為決策鏈。對于這些語言，我們認為它們一部分是面向基于“強制”的編程，另一部分則是專為處理圖形符號設(shè)</p><p>　　Alan Kay總結(jié)了Smalltalk的五大基本特征。這是第一種成功的面向?qū)ο蟪绦蛟O(shè)計語言，也是Java的基礎(chǔ)語言。通過這些特征，我們可理解“純粹”的面向?qū)ο蟪绦蛟O(shè)計方法是什么樣的。</p><p>　　(1)所有東西都是對

52、象?？蓪ο笙胂蟪梢环N新型變量；它保存著數(shù)據(jù)，但可要求它對自身進行操作。理論上講，可從要解決的問題身上提出所有概念性的組件，然后在程序中將其表達為一個對象。 (2) 程序是一大堆對象的組合；通過消息傳遞，各對象知道自己該做些什么。為了向?qū)ο蟀l(fā)出請求，需向那個對象“發(fā)送一條消息”。更具體地講，可將消息想象為一個調(diào)用請求，它調(diào)用的是從屬于目標對象的一個子例程或函數(shù)。 (3) 每個對象都有自己的存儲空間，可容納其他對象?；蛘哒f

53、，通過封裝現(xiàn)有對象，可制作出新型對象。所以，盡管對象的概念非常簡單，但在程序中卻可達到任意高的復雜程度。 (4) 每個對象都有一種類型。根據(jù)語法，每個對象都是某個“類”的一個“實例”。其中，“類”（Class）是“類型”（Type）的同義詞。一個類最重要的特征就是“能將什么消息發(fā)給它？”。 (5) 同一類所有對象都能接收相同的消息。這實際是別有含義的一種說法，大家不久便能理解。由于類型為“圓”（Circle）的一個對象也

54、屬于類型為“形狀”（Shape）的一個對象，所以一個圓完全能接收形狀消息。這意味著可讓程序代碼統(tǒng)一指</p><p>　　Light lt = new Light();</p><p>　　lt.on(); 在這個例子中，類型／類的名稱是Light，可向Light對象發(fā)出的請求包括包括打開（on）、關(guān)閉（off）、變得更明亮（brighten）或者變得更暗淡（dim）。通過簡單地聲

55、明一個名字（lt），我們?yōu)長ight對象創(chuàng)建了一個“句柄”。然后用new關(guān)鍵字新建類型為Light的一個對象。再用等號將其賦給句柄。為了向?qū)ο蟀l(fā)送一條消息，我們列出句柄名（lt），再用一個句點符號（.）把它同消息名稱（on）連接起來。從中可以看出，使用一些預先定義好的類時，我們在程序里采用的代碼是非常簡單和直觀的。 3、對象會提供服務(wù) 當你開發(fā)一個程序或者分析一個程序設(shè)計時，理解對象的最佳的方式是把他們當作“服務(wù)提供者”

56、。程序本身會為用戶提供服務(wù)，而它通過使用其它對象所提供的服務(wù)來完成這個工作。你的任務(wù)是制作（或者在更理想的情況下，從現(xiàn)有的代碼庫中找出）一組能為解決問題提供最佳服務(wù)的對象。</p><p>　　這么做的第一步是問“如果我可以像變魔術(shù)那樣把東西從帽子里拿出來，我該拿出些什么東西，哪些對象能立即幫我解決問題？”舉例來說，假設(shè)你要創(chuàng)建一個簿記程序。可能你會想應(yīng)該有一些保存預設(shè)的輸入界面的對象，一組進行簿記計算的對象，以

57、及一個能在各種打印機上打印支票和發(fā)票的對象。有些對象或許已經(jīng)有了，但是那些還沒有的應(yīng)該是什么樣的呢？它們應(yīng)該提供哪種服務(wù)，還有它們要完成任務(wù)的話，又該用哪些對象呢？如果你不斷分析下去，最終你會發(fā)現(xiàn)，不是“那個對象寫起來很容易”就是“那個對象已經(jīng)有了?！边@是將問題分解成一組對象的一個合理的方法。</p><p>　　將對象視作為服務(wù)的提供者還有一個額外的優(yōu)點：能提高對象的內(nèi)聚星。內(nèi)聚性高是高質(zhì)量的軟件設(shè)計一個基本要

58、求：就是說軟件的各種組將應(yīng)該能很好的“組裝在一起”。</p><p>　　設(shè)計對象時常犯的一個錯誤就是，往對象里塞了太多的功能。舉例來說，設(shè)計支票打印模塊的時候，你也許會決定設(shè)計一個能通曉所有排格式和打印工作細節(jié)的對象。很快你就會發(fā)現(xiàn)這個任務(wù)太艱巨了，或許應(yīng)該用三個或是更多對象來完成這個工作。第一個對象應(yīng)該是支票格式的目錄冊，通過查詢這個目錄冊可以獲取得該如何打印支票的信息。第二個對象，或是一組對象，應(yīng)該是能分辨

59、各種打印機的通用的打印接口。以及使用上述兩個對象所提供的服務(wù)的，能最終完成任務(wù)的第三個對象。由此每個對象都提供一組互補的功能。在一個良好的面向?qū)ο蟮脑O(shè)計中，每個對象都應(yīng)該只做一件事，并且做好一件事，而不是去做太多的事情。就像這里看到的，這樣不僅能發(fā)現(xiàn)那些對象因該買（打印機接口對象），而且能設(shè)計出今后能復用的對象（支票格式的目錄冊）。</p><p>　　將對象視作服務(wù)的提供者還是一種很了不起的簡化工具。它不僅在設(shè)