计算机专业毕业设计论文外文文献中英文翻译——JAVA对象.pdf

1 1 1 1. . . .introductionintroductionintroductionintroduction totototo objectsobjectsobjectsobjects 1.1 thethethethe progressprogressprogressprogress ofofofof abstractionabstractionabstractionabstraction all programming languages provide abstractions. it can be argued that the complexity of the problems youreable 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 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 their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. the programmer must establish the association between the machine model (in the “solution space,” which is the place where youre modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists). the effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire “programming methods” industry. the alternative to modeling the machine is to model the problem youre trying to solve. early languages such as lisp and apl chose particular views of the world (“all problems are ultimately lists” or “all problems 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 latter proved to be too restrictive.) each of theseapproaches is a good solution to the particular class of problem theyre designed to solve, but when you step outside of that domain they become awkward. the object-oriented approach goes a step further by providing tools for the programmer to represent elements in the problem space. this representation is general enough that the programmeris not constrained to any particular type of problem. we refer to the elements in the problem space and their representations in the solution spaceas “objects.”(you will also need other objects that dont have problem-space analogs.) the idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, youre reading words that also express the problem. this is a more flexible and powerful language abstraction than what weve had before. thus, oop allows you to describe the problem in terms of the problem, rather than in terms of the computer wherethe solution will run. theresstill a connection back to the computer: each object looks quite a bit like a little computerit has a state, and it has operations that you can ask it to perform.however, this doesnt seem like such a bad analogy to objects in the real worldthey all have characteristics and behaviors. alan kay summarized five basic characteristics of 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: 1.everythingeverythingeverythingeverything is is is is anananan object.object.object.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 problem youre trying to solve (dogs, buildings, services, etc.) and represent it as an object in your program. 2.a a a a programprogramprogramprogram is is is is a a a a bunchbunchbunchbunch ofofofof objectsobjectsobjectsobjects tellingtellingtellingtelling eacheacheacheach otherotherotherother whatwhatwhatwhat totototo dodododo bybybyby sendingsendingsendingsending messagesmessagesmessagesmessages. to make 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. 3.eacheacheacheach objectobjectobjectobject hashashashas itsitsitsits ownownownown memorymemorymemorymemory mademademademade upupupupofofofof otherotherotherotherobjectsobjectsobjectsobjects. 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 thesimplicity of objects. 4.everyeveryeveryevery objectobjectobjectobject hashashashas a a a a typetypetypetype. using the parlance, each object is aninstanceof aclass, in which “class” is synonymous with “type.” the most important distinguishing characteristic of a class is “what messages can you send to it?” 5.allallallall objectsobjectsobjectsobjects ofofofof a a a a particularparticularparticularparticular typetypetypetype cancancancan receivereceivereceivereceive thethethethesamesamesamesame messagesmessagesmessagesmessages. this is actually a loaded statement, as you will see later. because an object of type “circle” 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. thissubstitutabilityis one of the powerfulconcepts in oop. booch offersan even moresuccinct description of an object: an object has state, behavior and identity. 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 objectto put this in a concrete sense, each object has a unique address in memory. 1.2ananananobjectobjectobjectobject hashashashasananananinterfaceinterfaceinterfaceinterface aristotle was probably the first to begin a careful study of the concept oftype;he spoke of “the class of fishes 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, simula-67,with its fundamental keyword classclassclassclassthat introducesa new type into a program. simula, as its name implies, was created for developing simulations such as the classic “bank teller problem.” in this, you have a bunch of tellers, customers, accounts, transactions, and units of moneya lot of “objects.” objects that are identical except for their state during a programsexecution are grouped together into “classes of objects” and thatswhere the keyword classclassclassclass came from. creating abstract data types (classes) is a fundamental concept in object-oriented programming. abstract data types work almost exactly like built-in types: you can create variables of a type (calledobjectsorinstancesin object-oriented parlance) and manipulate those variables (calledsending messagesorrequests;you send a message and the object figures out what to do with it). the members (elements) of each class share some commonality: every account has a balance, every teller can accept a deposit, etc. at the same time, each member has its own state: each account has a different balance, each teller has a name. thus, the tellers, customers, accounts, transactions, etc., can each be represented with a unique entity in the computer program. this entity is the object, and each object belongs to a particular classthat defines its characteristics and behaviors. so, although what we really do in object-oriented programming is create new data types, virtually all object-oriented programming languages usethe “class” keyword. when you seethe word “type” think “class” and vice versa. since 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 characteristics 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 extend the programming language by adding new data types specific to your needs. the programming system welcomes the new classes and gives them all the care and type-checking that it gives to built-in types. the object-oriented approach is not limited to building simulations. whether or not you agree that any program is a simulation of the system youre designing, the use of oop techniques can easily reduce a large set of problems to a simple solution. once a class is established, you can make as many objects of that class as you like, and 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 elements in the problem space and objects in the solution space. 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 something, 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 itsinterface,and the type is what determines theinterface. a simple example might be a representation of a light bulb: light lt = new light(); lt.on(); theinterface establisheswhatrequestsyou can makefor a particular object. however, theremust be code somewhere to satisfy that request. this, along with the hidden data, comprises theimplementation. from a procedural programming standpoint, itsnot 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 saying that you “send a message” (make a request) to an object, and the object figures out what to do with that message (it executes code). light on() off() here, the name of the type/class is lightlightlightlight,the name of this particular lightlightlightlight object is lt lt lt lt, and the requests that you can make of a lightlightlightlight object are to turn it on, turn it off, make it brighter, or make it dimmer. you create a lightlightlightlight object by defining a “reference” (lt lt lt lt) for that object and calling newnewnewnewto request a new object of that type. to send a message to the object, you state the name of the object and connect it to the message request with aperiod (dot). from the standpoint of the user of a predefined class, thatspretty much all there is to programming with objects. the preceding diagram follows the format of theunified modeling 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 themethods(the functions that belong 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 methodsare shown in uml design diagrams, so themiddle portion is not shown.if youre interested only in theclass name, then the bottom portion doesnt need to beshown, either 1.3ananananobjectobjectobjectobject providesprovidesprovidesprovides services.services.services.services. while youretrying to develop or understand a program design, one of the best waysto think about objects is as “service providers.” your program 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 provide theideal services to solve your problem. a wayto 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, suppose 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 printing of checks and invoices on all different kinds of printers. maybe some of these objects already exist, and for the ones that dont,what would they look like? what services wouldthoseobjects provide, and what objects wouldtheyneed to fulfill their obligations? if you keep doing this, you will eventually reach a point where you can say either “that object seems simple enough to sit down and write” or “im sure that object must exist already.” this is a reasonable way to decomposea problem into aset of objects. thinking of an object as a serviceprovider has an additional benefit: it helps to improve the cohesiveness of the object.high cohesionis a fundamental quality of softwaredesign: it means that the various aspects of a softwarecomponent (such as an object, although this could also 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 decide you need an object that knowsall about formatting and printing. youll probably discover that this is too much for one object, and that what you need is three or moreobjects. one object might be a catalog of all the possible check layouts, which can be queried for information about how to print a check. one object or set of objects could be a generic printing interface that knows all about different kinds of printers (but nothing about bookkeepingthis one is a candidate for buying rather than writing yourself). and a third object could usethe services of the other two to accomplish the task.thus, each object has acohesive set of services it offers. in a good object-oriented design, each object does one thing well, but doesnt try to do too much. as seen here, this not only allows the discovery of objects that might be purchased (the printer interface object), but it also produces the possibility of an object that might be reused somewhereelse (thecatalog of check layouts). treating objects as service providers is a great simplifying tool, and itsvery useful not only during the design process, but also when someone else is trying to understand your code or reusean objectif they can seethe value of the object based on what serviceit provides, it makes it much easier to fit it into the design. 1. 对象入门 1.1 抽象的进步 所有编程语言的最终目的都是提供一种“抽象”方法。一种较有争议的说法是：解决问题的复杂 程度直接取决于抽象的种类及质量。 这儿的“种类”是指准备对什么进行“抽象”？汇编语言是对基础 机器的少量抽象。后来的许多“命令式”语言（如 fortran，basic 和 c）是对汇编语言的一种抽象。 与汇编语言相比， 这些语言已有了长足的进步， 但它们的抽象原理依然要求我们着重考虑计算机的结构 ， 而非考虑问题本身的结构。 在机器模型 （位于“方案空间”） 与实际解决的问题模型 （位于“问题空间”） 之间，程序员必须建立起一种联系。这个过程要求人们付出较大的精力，而且由于它脱离了编程语言本 身的范围，造成程序代码很难编写，而且要花较大的代价进行维护。由此造成的副作用便是一门完善的 “编程方法”学科。 为机器建模的另一个方法是为要解决的问题制作模型。对一些早期语言来说，如 lisp 和 apl，它 们的做法是“从不同的角度观察世界”“所有问题都归纳为列表”或“所有问题都归纳为算法”。 prolog 则将所有问题都归纳为决策链。对于这些语言，我们认为它们一部分是面向基于“强制”的编 程，另一部分则是专为处理图形符号设计的。每种方法都有自己特殊的用途，适合解决某一类的问题。 但只要超出了它们力所能及的范围，就会显得非常笨拙。 面向对象的程序设计在此基础上则跨出了一大步，程序员可利用一些工具表达问题空间内的元素。 由于这种表达非常普遍，所以不必受限于特定类型的问题。我们将问题空间中的元素以及它们在方案空 间的表示物称作“对象”（object）。当然，还有一些在问题空间没有对应体的其他对象。通过添加新 的对象类型，程序可进行灵活的调整，以便与特定的问题配合。所以在阅读方案的描述代码时，会读到 对问题进行表达的话语。与我们以前见过的相比，这无疑是一种更加灵活、更加强大的语言抽象方法。 总之，oop 允许我们根据问题来描述问题，而不是根据方案。然而，仍有一个联系途径回到计算机。每 个对象都类似一台小计算机；它们有自己的状态，而且可要求它们进行特定的操作。与现实世界的“对 象”或者“物体”相比，编程“对象”与它们也存在共通的地方：它们都有自己的特征和行为。 alan kay 总结了 smalltalk 的五大基本特征。 这是第一种成功的面向对象程序设计语言， 也是java 的基础语言。通过这些特征，我们可理解“纯粹”的面向对象程序设计方法是什么样的。 (1)所有东西都是对象。可将对象想象成一种新型变量；它保存着数据，但可要求它对自身进行操 作。理论上讲，可从要解决的问题身上提出所有概念性的组件，然后在程序中将其表达为一个对象。 (2) 程序是一大堆对象的组合； 通过消息传递， 各对象知道自己该做些什么。 为了向对象发出请求 ， 需向那个对象“发送一条消息”。更具体地讲，可将消息想象为一个调用请求，它调用的是从属于目标 对象的一个子例程或函数。 (3) 每个对象都有自己的存储空间，可容纳其他对象。或者说，通过封装现有对象，可制作出新型 对象。所以，尽管对象的概念非常简单，但在程序中却可达到任意高的复杂程度。 (4) 每个对象都有一种类型。根据语法，每个对象都是某个“类”的一个“实例”。其中，“类” （class）是“类型”（type）的同义词。一个类最重要的特征就是“能将什么消息发给它？”。 (5) 同一类所有对象都能接收相同的消息。这实际是别有含义的一种说法，大家不久便能理解。由 于类型为“圆”（circle）的一个对象也属于类型为“形状”（shape）的一个对象，所以一个圆完全 能接收形状消息。这意味着可让程序代码统一指挥“形状”，令其自动控制所有符合“形状”描述的对 象，其中自然包括“圆”。这一特性称为对象的“可替换性”，是 oop 最重要的概念之一。 一些语言设计者认为面向对象的程序设计本身并不足以方便解决所有形式的程序问题， 提倡将不同 的方法组合成“多形程序设计语言”。 1.21.2 对象的接口对象的接口 亚里士多德或许是认真研究“类型”概念的第一人，他曾谈及“鱼类和鸟类”的问题。在世界首例 面向对象语言 simula-67 中，第一次用到了这样的一个概念： 所有对象尽管各有特色都属于某一系列对象的一部分，这些对象具有通用的特征和行为。在 simula-67 中，首次用到了 class 这个关键字，它为程序引入了一个全新的类型（clas 和 type 通常可 互换使用；注释）。 ：有些人进行了进一步的区分，他们强调“类型”决定了接口，而“类”是那个接口的一种特殊 实现方式。 simula 是一个很好的例子。正如这个名字所暗示的，它的作用是“模拟”（simulate）象“银行 出纳员”这样的经典问题。在这个例子里， 我们有一系列出纳员、客户、 帐号以及交易等。每类成员 （元 素）都具有一些通用的特征：每个帐号都有一定的余额；每名出纳都能接收客户的存款；等等。与此同 时，每个成员都有自己的状态；每个帐号都有不同的余额；每名出纳都有一个名字。所以在计算机程序 中，能用独一无二的实体分别表示出纳员、客户、帐号以及交易。这个实体便是“对象”，而且每个