Page 322
ANALYSIS
Lines 9_12 instantiate four new building objects. The remainder of the
PL/SQL block compares these building objects against each other; see lines 15, 20, and
24. In each of these cases a relational operator is used to compare one
building object to another. When executing these comparisons, Oracle automatically calls the
ORDER method defined for this object type. The
ORDER method then determines the result of the comparison.
MAP functions provide an alternative way to specify comparison semantics for an object type. A MAP function enables you to compute a single scalar value, based on one or more of the object's attributes, which is then used to compare the object in question to other objects of the same type.
MAP functions have no parameter because their purpose is to return a value representing only the object whose MAP method was invoked. The result of a MAP function must be one of the following types:
When comparing two objects with MAP methods defined, Oracle first calls the MAP function for each object and then compares the two results.
| NOTE |
It is possible to write a MAP function for the building object type, which would return the building name for comparison purposes. This could be used instead of the ORDER function. |
Although the object features introduced in Oracle8 represent a significant step forward for Oracle, there are some limitations of which you should be aware. These limitations are listed following:
Page 323
Some of these limitations are fairly significant. The lack of support for private attributes, for example, means that anyone using your objects is free to bypass whatever accessor and mutator methods you have defined. In more mature object-oriented languages, you can protect attributes, allowing them to be set only by member functions, which then contain code to validate the values being set. Another issue here is that you cannot separate implementation-specific attributes from those which you intend to be publicly referenced.
The inability to write your own constructor functions also serves to limit your opportunities to validate attribute values. Validation at object creation is impossible because the default constructors simply set the attributes to whatever values you supply. If you were dealing with an employee object, for example, you could easily instantiate it with a negative salary.
Inheritance is a key feature of any object-oriented language, and it is a feature that Oracle does not yet support. The other limitations are not as significant as the first three. The 1,000-attribute limit is probably not one you will often run up against. The datatype limitation is related to the fact that all object types must be declared at the database level, and although it might be convenient to be able to define object types local to a PL/SQL procedure, you wouldn't be able to store those objects permanently in the database.
The object-oriented features of Oracle8 described in this chapter represent a significant step forward in the effort to marry object and relational technologies, in the process providing Oracle developers with access to some of the same powerful object-oriented features enjoyed by developers using languages such as C++ and Java. Oracle now supports the definition and creation of objects, complete with methods and attributes. These objects can be stored in the database as attributes of other objects, columns in a table, or as rows in an object table. In addition, you can still access your data using standard, relational methods. This can ease your transition to object-oriented programming and lets you still use relational queries in cases where they are most efficient.
Q Why is encapsulation so important?
A Encapsulation provides two benefits. It provides for reusability and lessens the amount of detail you need to remember about an object's implementation. When an object's functionality is exposed through a well-defined interface, you no longer have to worry about all the details behind that interface. You just call the methods and let the object do its work. Encapsulation also aids in reusability because all the necessary code is part of the object definition, making it easy to drop that definition into other programs.
Page 324
Q When I create objects based on an object type, is the code for all the methods replicated for each instance of the object?
A No, the code for the member functions and procedures is not duplicated for each instance of an object type. The function and procedure code exists in one place; only the object's attributes are distinct. Oracle always passes the SELF parameter to each member function and procedure to ensure that the proper attributes are referenced. Usually this is done transparently to you, so conceptually it is easy to think of each object having its own methods.
Q What are accessor and mutator methods?
A Accessor methods are member functions that exist primarily to enable you to retrieve specific attribute values from an object. Mutator methods are member procedures that enable you to set the value of a specific attribute or set of attributes. Using accessor and mutator methods helps insulate your code from changes to an object's underlying implementation.
Q When should I use an object table to store objects, and when should I store objects as a single column in a table?
A The answer to this depends on how you will use the objects in question. Generally, if an object has meaning only in the context of a parent object, you can store it as a column. Objects that stand alone and need to be referenced by several other objects must be stored in object tables.
Q When do I need to worry about the SELF parameter?
A Rarely. You only need to worry about the SELF parameter when you want to use an input/output mode different from the default. For example, the SELF parameter of a member function is by default input only. This means that by default a member function cannot change an object's attributes. To change this behavior and allow a member function to update an attribute, you would need to explicitly declare the SELF parameter as an IN OUT parameter.
Use the following workshop to test your comprehension of this chapter and put what you've learned into practice. You'll find the answers to the quiz and exercises in Appendix A, "Answers."