Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-04-09
2001-04-24
Oberley, Alvin E. (Department: 2755)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06223227
ABSTRACT:
BACKGROUND OF THE PRESENT INVENTION
1. Field of the Invention
This invention relates to the field of object-oriented programming. Specifically, it relates to a method of providing stand-in objects in an object-oriented programming environment.
2. Background Art
Object-oriented programming is a method of creating computer programs by combining certain fundamental building blocks, and creating relationships among and between the building blocks. The building blocks in object-oriented programming systems are called “objects.” An object is a programming unit that groups together a data structure (instance variables) and the operations (methods) that can use or affect that data. Thus, an object consists of data and one or more operations or procedures that can be performed on that data. The joining of data and operations into a unitary building block is called “encapsulation.” In object-oriented programming, operations that can be performed on the data are referred to as “methods.”
An object can be instructed to perform one of its methods when it receives a “message.” A message is a command or instruction to the object to execute a certain method. It consists of a method selection (name) and arguments that are sent to an object. A message tells the receiving object what to do.
One advantage of object-oriented programming is the way in which methods are invoked. When a message is sent to an object, it is not necessary for the message to instruct the object how to perform a certain method. It is only necessary to request that the object execute the method. This greatly simplifies program development.
Object-oriented programming languages are generally based on one of two schemes for representing general concepts and sharing knowledge. One scheme is known as the “class” scheme. The other scheme is known as the “prototype” scheme. Both the class-based and prototype-based object-oriented programming schemes are generally described in Lieberman, “Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems,” OOPSLA 86 Proceedings, September 1986, pp. 214-223.
Class Scheme
An object that describes behavior is called a “class.” Objects that acquire a behavior and that have states are called “instances.” Thus, in the Objective C language, which is the computer language in which the preferred embodiment of the present invention may be implemented, a class is a particular type of object. In Objective C, any object that is not a class object is said to be an instance of its class. The classes form a “hierarchy.” Each subclass in the hierarchy may add to or modify the behavior specified by its parent class and may also add additional states.
An object in Objective C may couple its data with the methods for operating on that data. However, when the data for an object is part of a relational database, the relationships among the stored data may also be retrieved, or “fetched.” For example, in an relational database where both Employee and Department information is stored, the Employee and Department information may be related (e.g., have a related column or columns). In such a case, once Employee data is retrieved to instantiate an Employee object, a corresponding Department object is also created and instantiated with data from the database that is related to the data from the Employee object. This process of instantiating a Department object with the data related to the instantiated Employee object is referred to as resolving the relationship between the Employee and Department objects.
If a fetched object has many relationships that are to be resolved when the object is fetched, system resources (e.g., processing time and memory) are consumed during the fetch operation to resolve the relationships. For example, an object is fetched that has relationships with other objects in the database and these other objects have relationships with still other objects in the database, a fetch operation is performed for each related object. For example, an Employee object may have relationships with objects such as Department, Employee ID, Salary, Start Date, Vacation Days, Sick Days, Health Benefits and Office. Fetching of the Employee object causes a fetch of all of these objects, as well as the data to fill these objects. Also, any objects related to these objects are also retrieved, causing unnecessary interaction with the database server, and significantly increasing processing time and memory requirements. When all of an object's relationships are resolved regardless of whether a related object is needed, the processing time and memory requirements expended to resolve the relationships is wasted.
One prior art solution is to create an intermediate object called a “handle.” The handle acts as a “go-between” and is used to reference objects related to a fetched object. For example, after the Employee object is fetched, the handle for the related Department object is created instead of the actual Department object. The handle may take any of various forms, such as a pointer to a pointer, a function call, a name look-up in a dictionary, or a method on some object. When code in the Employee object wishes to access the Department object, it must ask the handle for the information. The first time the Department object is accessed, the Department object is instantiated and stored in memory.
One disadvantage of this prior art method is that the program must always direct messages and inquiries to the Department object through the Department handle. The Employee object does not have direct access to the Department object or the Department data. Thus, an extra level of interaction and complexity to the code is created. Since not all objects get handles, different code must be written to interact with objects that have handles (e.g., the Department object) than to interact with regular objects without handles. Further, objects with handles look and behave differently than all other objects in the programming environment. Existing function libraries or other pieces of code written to manipulate regular objects will not work with handles because they expect to interact with the objects directly. Consequently, duplicate algorithms must then be written to interact with both handles and regular objects.
Another prior art method for dealing with this problem involves using the virtual memory system of the computer. In this scheme, when a pointer to a particular object is referenced, the virtual memory page faulting mechanism determines which page of memory contains the referenced object, and then retrieves the entire page. For example, when the Employee object wishes to access the Department object, a page fault is invoked, and the page of memory that contains the Department object is retrieved.
One disadvantage of this prior art scheme is that it is dependent on the virtual memory and API constraints of the virtual memory system of the computer system. Another disadvantage of this scheme is that more information is retrieved than is necessary, since an entire page of memory is retrieved for a reference to a single object. That is, for example, every object whose virtual address is contained in the page retrieved must be retrieved regardless of whether the object is actually needed. Further, a virtual memory system must be modified to access data from a conventional database system. For example, there must be some means for associated a virtual address of a referenced object and the data that must be fetched from the database to instantiate the object. When a page fault occurs, for example, the rowid of each row containing data for the objects whose virtual addresses are contained in the page must be determined and then used to fetch the data from the database to instantiate each object.
Thus, a flexible method for providing object fetching with reduced database server interaction and simplified code requirements is desired.
SUMMARY OF THE INVENTION
The present invention provides a method for delaying the instantiation of an object in an object-oriented environment. Instead of creating an ac
Greenfield Jack
Upson Linus
Willhite Daniel
Williamson Richard
Courtenay III St. John
NeXT Software, Inc.
Oberley Alvin E.
The Hecker Law Group
LandOfFree
Method for providing stand-in objects does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for providing stand-in objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for providing stand-in objects will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2478470