1、 附录 1. 外文文献 Introduction To Objects 1、 The progress of abstraction All programming languages provide abstractions. It can be argued that the complexity of the problems youre able to solve is directly related to the kind and quality of abstraction. By “kind” I mean, “What is it that you are abstracti
2、ng?” 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 requir
3、es 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
4、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 mai
5、ntain, 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 alg
6、orithmic,” 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 these approaches is a good solution to the
7、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 progra
8、mmer 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.” (You will also need other objects that dont have problem-space analogs.) The idea is that the program is allowed to adapt itself to t
9、he 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
10、the problem, rather than in terms of the computer where the solution will run. Theres still 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 t
11、o 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 pro
12、gramming: Everything 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 problem youre trying to solve (dogs, buildings, services, etc.) an
13、d represent it as an object in your program. A program is a bunch of objects telling each other what to do by sending messages. 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
14、object. Each object has its own 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 objects. Every object has a type. Using the parlan
15、ce, each object is an instance of a class, in which “class” is synonymous with “type.” The most important distinguishing characteristic of a class is “What messages can you send to it?” All objects of a particular type can receive the same messages. This is actually a loaded statement, as you will s
16、ee 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. This substitutability is one of the powerful con
17、cepts in OOP. Booch offers an even more succinct 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 t
18、his in a concrete sense, each object has a unique address in memory. 2、 An object has an interface Aristotle was probably the first to begin a careful study of the concept of type； he spoke of “the class of fishes and the class of birds.” The idea that all objects, while being unique, are also part
19、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 class that introduces a new type into a program. Simula, as its name implies, was created for developing simulations such as the cl
20、assic “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 programs execution are grouped together into “classes of objects” and thats where the keyword class c
21、ame 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 (called objects or instances in object-oriented parlance) and manipulate those variables (called s
22、ending messages or requests； 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 differ
23、ent 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 class that defines its characteristics and behaviors. So, although
24、 what we really 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. 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
