218 THE RUN-TIME STRUCTURE:OBJECTS $8.1 8.1 OBJECTS At any time during its execution,an O-O system will have created a certain number of objects.The run-time structure is the organization of these objects and of their relations. Let us explore its properties. What is an object? First we should recall what the word "object"means for this discussion.There is nothing The definition vague in this notion;a precise technical definition was given in the previous chapter: appeared on page 166.See also the Object rule,page Definition:object 171. An object is a run-time instance of some class. A software system that includes a class C may at various points of its execution create(through creation and cloning operations,whose details appear later in this chapter) instances of C;such an instance is a data structure built according to the pattern defined by C;for example an instance of the class PO/NT introduced in the previous chapter is a data structure consisting of two fields,associated with the two attributes x and y declared in the class.The instances of all possible classes constitute the set of objects. The above definition is the official one for object-oriented software.But "object" also has a more general meaning,coming from everyday language.Any software system is related to some external system,which may contain "objects":points,lines,angles, surfaces and solids in a graphics system:employees,pay checks and salary scales in a payroll system;and so on.Some of the objects created by the software will be in direct correspondence with such external objects,as in a payroll system that includes a class EMPLOYEE,whose run-time instances are computer models of employees. This dual use of the word"object"has some good consequences,which follow from “Direct Mapping”, the power of the object-oriented method as a modeling tool.Better than any other method,page47. object technology highlights and supports the modeling component of software development.This explains in part the impression of naturalness which it exudes,the attraction it exerts on so many people,and its early successes-still among the most visible-in such areas as simulation and user interfaces.The method here enjoys the direct mapping property which an earlier chapter described as a principal requirement of good modular design.With software systems considered to be direct or indirect models of real systems,it is not surprising that some classes will be models of external object types from the problem domain,so that the software objects(the instances of these classes)are themselves models of the corresponding external objects. But we should not let ourselves get too carried away by the word"object".As always in science and technology,it is a bit risky to borrow words from everyday language and give them technical meanings.(The only discipline which seems to succeed in this delicate art is mathematics,which routinely hijacks such innocent words as "neighborhood", s“variety”or“barrel'”and uses them with completely unexpected meanings一perhaps the218 THE RUN-TIME STRUCTURE: OBJECTS §8.1 8.1 OBJECTS At any time during its execution, an O-O system will have created a certain number of objects. The run-time structure is the organization of these objects and of their relations. Let us explore its properties. What is an object? First we should recall what the word “object” means for this discussion. There is nothing vague in this notion; a precise technical definition was given in the previous chapter: A software system that includes a class C may at various points of its execution create (through creation and cloning operations, whose details appear later in this chapter) instances of C; such an instance is a data structure built according to the pattern defined by C; for example an instance of the class POINT introduced in the previous chapter is a data structure consisting of two fields, associated with the two attributes x and y declared in the class. The instances of all possible classes constitute the set of objects. The above definition is the official one for object-oriented software. But “object” also has a more general meaning, coming from everyday language. Any software system is related to some external system, which may contain “objects”: points, lines, angles, surfaces and solids in a graphics system: employees, pay checks and salary scales in a payroll system; and so on. Some of the objects created by the software will be in direct correspondence with such external objects, as in a payroll system that includes a class EMPLOYEE, whose run-time instances are computer models of employees. This dual use of the word “object” has some good consequences, which follow from the power of the object-oriented method as a modeling tool. Better than any other method, object technology highlights and supports the modeling component of software development. This explains in part the impression of naturalness which it exudes, the attraction it exerts on so many people, and its early successes — still among the most visible — in such areas as simulation and user interfaces. The method here enjoys the direct mapping property which an earlier chapter described as a principal requirement of good modular design. With software systems considered to be direct or indirect models of real systems, it is not surprising that some classes will be models of external object types from the problem domain, so that the software objects (the instances of these classes) are themselves models of the corresponding external objects. But we should not let ourselves get too carried away by the word “object”. As always in science and technology, it is a bit risky to borrow words from everyday language and give them technical meanings. (The only discipline which seems to succeed in this delicate art is mathematics, which routinely hijacks such innocent words as “neighborhood”, “variety” or “barrel” and uses them with completely unexpected meanings — perhaps the Definition: object An object is a run-time instance of some class. The definition appeared on page 166. See also the Object rule, page 171. “Direct Mapping”, page 47