毕业论文5000字英文文献翻译文档格式.docx

1、ve seen already, such as istream and ostream, are all defined as classesthat is,they are not strictly speaking part of the language. Complete understanding of the class mechanism requires mastering a lot of information. Fortunately, it is possible to use a class that someone else has written without

2、 knowing how to define a class ourselves. In this section, well describe a simple class that we canuse in solving our bookstore problem. Well implement this class in the subsequent chapters as we learn more about types,expressions, statements, and functionsall of which are used in defining classes.

3、To use a class we need to know three things: What is its name? Where is it defined? What operations does it support? For our bookstore problem, well assume that the class is named Sales_item and that it is defined in a header named Sales_item.h. The Sales_item Class The purpose of the Sales_item cla

4、ss is to store an ISBN and keep track of the number of copies sold, the revenue, and average sales price for that book. How these data are stored or computed is not our concern. To use a class, we need not know anything about how it is implemented. Instead, what we need to know is what operations th

5、e class provides. As weve seen, when we use library facilities such as IO, we must include the associated headers. Similarly, for our own classes, we must make the definitions associated with the class available to the compiler. We do so in much the same way. Typically, we put the class definition i

6、nto a file. Any program that wants to use our class must include that file. Conventionally, class types are stored in a file with a name that, like the name of a program source file, has two parts: a file name and a file suffix. Usually the file name is the same as the class defined in the header. T

7、he suffix usually is .h, but some programmers use .H, .hpp, or .hxx. Compilers usually arent picky about header file names, but IDEs sometimes are. Well assume that our class is defined in a file named Sales_item.h. Operations on Sales_item Objects Every class defines a type. The type name is the sa

8、me as the name of the class. Hence, our Sales_item class defines a type namedSales_item. As with the built-in types, we can define a variable of a class type. When we write Sales_item item we are saying that item is an object of type Sales_item. We often contract the phrase an object of type Sales_i

9、tem toaSales_ item object or even more simply to a Sales_item. In addition to being able to define variables of type Sales_item, we can perform the following operations on Sales_item objects: Use the addition operator, +, to add two Sales_items, Use the input operator, to write a Sales_item object,

10、Use the assignment operator, =, to assign one Sales_item object to another, Call the same_isbn function to determine if two Sales_items refer to the same book. Classes are central to most C+ programs: Classes let us define our own types that are customizedfor the problems we need to solve, resulting

11、 in applications that are easier to write and understand.Well-designed class types can be as easy to use as the built-in types. A class defines data and function members: The data members store the state associated with objectsof the class type, and the functions perform operations that give meaning

12、 to the data. Classeslet us separate implementation and interface. The interface specifies the operations that the classsupports. Only the implementor of the class need know or care about the details of the implementation. This separation reduces the bookkeeping aspects that make programming tedious

13、 anderror-prone. Class types often are referred to as abstract data types. An abstract data type treats the data（state） and operations on that state as a single unit. We can think abstractly about what the classd oes, rather than always having to be aware of how the class operates. Abstract data typ

14、es arefundamental to both object-oriented and generic programming. Data abstraction is a programming （and design） technique that relies on the separation of interfaceand implementation. The class designer must worry about how a class is implemented, but programmersthat use the class need not know about these details. Instead, programmers who use a type need to know only the types interface; they can think abstractly about what the type does rather than concret