Data processing with policed object union

Details Data processing with policed object union Data processing with policed object union

2000-04-04

2004-07-06

Lee, Thomas (Department: 2126)

Electrical computers and digital processing systems: interprogra

Interprogram communication using message

Object oriented message

C717S116000

Reexamination Certificate

active

06760913

ABSTRACT:

FIELD OF THE INVENTION
This invention relates to the data processing field. More specifically, this invention relates to Object Oriented Programming environments.
BACKGROUND OF THE INVENTION
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have found their way into just about every aspect of the American life style. One reason for this proliferation is the ability of computer systems to perform a variety of tasks in an efficient manner. The mechanisms used by computer systems to perform these tasks are called computer programs.
Like computer systems themselves, the development of computer programs has evolved over the years. The EDVAC system used what was called a “one address” computer programming language. This language allowed for only the most rudimentary computer programs. By the early 1950s, scientists had developed mechanisms which could convert symbolic instructions that were reasonably understandable to humans into a form which could be understood by a computer system. Each computer system was designed to handle a specific group of these instructions. These groups of instructions are called instruction sets.
The next step in the development of computer programs was the notion of computer programming languages. Computer programming languages were even more understandable than symbolic instruction sets. Computer programs are written using a variety of computer programming languages. Once written, a computer program is compiled into instructions that are part of the instruction set of a particular computer system. FORTRAN is usually cited as one of the first languages to allow computer programs to be written independently of a particular instruction set. By the 1960s, improvements in computer programming languages led to computer programs that were so large and complex that it was difficult to manage and control their development and maintenance.
Hence, in the 1970s, focus was directed away from developing new programming languages towards the development of programming methodologies and environments which could better accommodate the increasing complexity and cost of large computer programs. One such methodology is the Object Oriented Programming (OOP) approach. OOP advocates claim that this approach to computer programming can improve the productivity of computer programmers by as much as twenty-five fold. Hence, while it has been some time since the OOP concept was originally developed, it is currently seen as the way of the future.
The two fundamental concepts of OOP are “encapsulation” and “reusability.” Encapsulation means that information and the means for using the information are conceptually packaged into individual entities called “objects.” The objects represent individual operations or groups of operations that can be performed by a computer system. The information contained in an object is called data and the means used to perform a particular operation upon the information is called a method. The idea of reusability is that the objects are made sufficiently generic so that they can be used by the methods of many other objects. Any program or method program that uses an object is said to be a client of that object (i.e., a client program). The client will call or invoke the object while specifying the method that is to be used. This is called method resolution.
Objects are also considered to be members of a particular “class” of objects. When objects are created they may be members of a particular class or they may be considered to be members of a subclass of a particular class. Objects that are created as members of a subclass are said to have “inherited” the characteristics (i.e., the data and methods) of the class to which they are a subclass (i.e., their super class). For example, consider a class of objects called Canine. The class will have data that describes objects of that class (i.e., name, colour, number of eyes and legs, etc.) The class will also have methods defined which can be used to work with the data of the class. For example, an object of class Canine could be an object that represented a canine named REX that was black and had two eyes and four legs. A subclass of class Canine, class Dog, could further define class Canine to include data that indicated what type of canine Was involved. For example, an object of class Dog could be created that represented a dog named Lassie that was white and brown, had two eyes, four legs, and was of type Collie. Class Canine would also, then, be considered a super class of class Dog. As objects and subclasses are added, a hierarchical tree structure is created. Each class, be it respectively referred to as a subclass or super class, is considered to be at a certain level in the hierarchical structure. In the example, class Dog, as a subclass of class Canine, would be at a level one greater than that of class Canine.
According to the present state of the art, e.g., the Interface Definition Language (IDL) or Microsoft's COM (Common Object Model)/ActiveX/OLE (Object Linking and Embedding), when an object is being defined all of the methods which this object supports are embedded in a text file which is then used to generate Object Method templates.
It is very common to define one object (e.g., object AX) as containing other objects (e.g., objects B1 and B2). AX is then known as an object union of B1 and B2. When this is done, all of the methods that are publicly available in B1 and B2 become also publicly accessible from AX. That is, if object B1 supports methods m,n,o,p and object B2 supports methods k,l,m,n then an external object can make method calls on AX using the following methods: B1.m, B1.n, B1.o, B1.p, B2.k, B2.1, B2.m, B2.n. However, oftentimes it is advantageous to define AX so that only some of the B1 and/or B2 methods are publicly accessible via AX. For example, for reasons of security or performance it may be required that only methods whose names are common to B1 and B2 be publicly accessible via AX.
The usual way this restriction has been carried out according to the present state of the art is to create a subclass c1 of B1 and a subclass C2 of B2, such subclasses hiding the undesired implementations and methods. However, this involves a compile or definition time activity and thus the inventors have found that this includes inflexible limitations, such as a high degree of programming redundancy in order to obtain the desired methods.
Specifically, there are several areas of programming where such a dynamic inheritance is useful. Consider the case where an Object is to have different behaviours based on some criteria, for example, time. We call this object the DayNight Object which is instantiated from a Class called DayNightClass (the concept of Class Factories is not relevant to this discussion). The object has a given behaviour during working hours, but another behaviour during the night.
Under the OO programming technique now widely used, this Object would normally be instantiated from two different Classes: Day and Night. This would mean that two new Classes are setup, both inheriting from the DayNightClass: DayFromDayNightClass and NightFromDayNightClass; both of these derived Classes contain the same methods—it is the implementation that differs. Thus, the application program has to instantiate a DayFromDayNightClass or a NightFromDayNightClass object.
The logic for determining whether a Day Object or a Night Object is to be instantiated, therefore, lies in the application that creates the Object. According to a pure view of the Object Oriented paradigm, this is the wrong place for a decision to be made about the function of the Object—it is the Object itself that should determine its mode of operation. The present invention presents a technique for removing this corruption of the pure OO paradigm.
Another technique is to supply a parameter at instantiation time. This permits the instantiation of a DayNightClass object to always be performed, with the instantiation parameter being saved

Affiliated with

Also associated with

Rating

Data processing with policed object union does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Data processing with policed object union, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Data processing with policed object union will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3224526