【正文】 The interface 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, prises the implementation. From a procedural programming standpoint, it’s not that plicated. 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 . 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 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 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 a predefined class, that’s pretty much all there is to programming with objects. The preceding diagram follows the format of the Unified 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 the methods 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 methods are shown in UML design diagrams, so the middle portion is not shown. If you’re interested only in the class name, then t he bottom portion doesn’t need to be shown, either An object provides services. 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 program itself will provide services to the user, and it will acplish 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 the ideal services to solve your problem. 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, suppose you are creating a bookkeeping program. You might imagine some objects that contain predefined 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 don’t, what would they look like? What services would those objects provide, and what objects would they need 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。 you send a message and the object figures out what to do with it . The members elements of each class share some monality: 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 puter program. This entity is the object, and each object belongs to a particular class that defines its characteristics and behaviors. So, although what we really do in objectoriented programming is create new data types, virtually all objectoriented programming languages use the “cl ass” 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 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 weles the new classes and gives them all the care and typechecking that it gives to builtin types. The objectoriented approach is not limited to building simulations. Whether or not you agree that any program is a simulation of the system you’re 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 objectoriented programming is to create a onetoone 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 plete 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 is what determines the interface. A simple example might be a representation of a light bulb: Light On Off Light lt new Light 。 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 ponent in the problem you’re tr ying to solve dogs, buildings, services, etc. and represent it as an object in your program. A program is a bunch of o