面向?qū)ο蟪绦蛟O(shè)計(jì)外文翻譯2_第1頁(yè)
已閱讀1頁(yè),還剩9頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶(hù)提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、<p>  附 錄1. 外文文獻(xiàn)</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>  對(duì)象入門(mén)</b></p>

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

50、機(jī)器模型(位于“方案空間”)與實(shí)際解決的問(wèn)題模型(位于“問(wèn)題空間”)之間,程序員必須建立起一種聯(lián)系。這個(gè)過(guò)程要求人們付出較大的精力,而且由于它脫離了編程語(yǔ)言本身的范圍,造成程序代碼很難編寫(xiě),而且要花較大的代價(jià)進(jìn)行維護(hù)。由此造成的副作用便是一門(mén)完善的“編程方法”學(xué)科。 為機(jī)器建模的另一個(gè)方法是為要解決的問(wèn)題制作模型。對(duì)一些早期語(yǔ)言來(lái)說(shuō),如LISP和APL,它們的做法是“從不同的角度觀察世界”——“所有問(wèn)題都?xì)w納為列表”或“所有問(wèn)題

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

52、象。可將對(duì)象想象成一種新型變量;它保存著數(shù)據(jù),但可要求它對(duì)自身進(jìn)行操作。理論上講,可從要解決的問(wèn)題身上提出所有概念性的組件,然后在程序中將其表達(dá)為一個(gè)對(duì)象。 (2) 程序是一大堆對(duì)象的組合;通過(guò)消息傳遞,各對(duì)象知道自己該做些什么。為了向?qū)ο蟀l(fā)出請(qǐng)求,需向那個(gè)對(duì)象“發(fā)送一條消息”。更具體地講,可將消息想象為一個(gè)調(diào)用請(qǐng)求,它調(diào)用的是從屬于目標(biāo)對(duì)象的一個(gè)子例程或函數(shù)。 (3) 每個(gè)對(duì)象都有自己的存儲(chǔ)空間,可容納其他對(duì)象。或者說(shuō)

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

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

55、明一個(gè)名字(lt),我們?yōu)長(zhǎng)ight對(duì)象創(chuàng)建了一個(gè)“句柄”。然后用new關(guān)鍵字新建類(lèi)型為L(zhǎng)ight的一個(gè)對(duì)象。再用等號(hào)將其賦給句柄。為了向?qū)ο蟀l(fā)送一條消息,我們列出句柄名(lt),再用一個(gè)句點(diǎn)符號(hào)(.)把它同消息名稱(chēng)(on)連接起來(lái)。從中可以看出,使用一些預(yù)先定義好的類(lèi)時(shí),我們?cè)诔绦蚶锊捎玫拇a是非常簡(jiǎn)單和直觀的。 3、對(duì)象會(huì)提供服務(wù) 當(dāng)你開(kāi)發(fā)一個(gè)程序或者分析一個(gè)程序設(shè)計(jì)時(shí),理解對(duì)象的最佳的方式是把他們當(dāng)作“服務(wù)提供者”

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

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

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

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

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶(hù)所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 眾賞文庫(kù)僅提供信息存儲(chǔ)空間,僅對(duì)用戶(hù)上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶(hù)上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶(hù)因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論