Interoperability
The interoperability of a DataBlade module refers to how well that module works with Informix Dynamic Server with Universal Data Option, and with other DataBlade modules.
This section discusses the following interoperability issues:
Orthogonality
In an orthogonal system, such as an object-relational database, the various parts work together in a natural, semantically logical way. For example, an orthogonal DataBlade module provides solutions only for the problems it is intended to solve, and it relies on the Informix server or other DataBlade modules to solve problems outside of its domain. Similarly, an orthogonal DataBlade module allows other DataBlade modules to use its facilities in a natural, semantically logical way.
The SimpleMap DataBlade module, for example, does not implement full-text search. It is more effective if developers who are experts in text search facilities create DataBlade modules that satisfy this requirement. The SimpleMap DataBlade module can then supply just geospatial functionality; it does not need to define routines over types that it does not create.
A simple guideline for ensuring orthogonality in DataBlade module development is, "It does a small number of things well."
Simple, Clean Interfaces
Provide the users of your DataBlade module with a simple, clean interface by following these guidelines where possible:
This section discusses each of these guidelines.
Naming Routines
Whenever possible, use generally accepted names for routines using your new data types. For example, the Overlaps() routine in the SimpleMap DataBlade module does precisely what its name indicates. Users know what to expect when they call it, and the name is an important piece of documentation for the routine.
Because Informix Dynamic Server supports polymorphism (see "Taking Advantage of Polymorphism"), it is possible that another routine of the same name already exists in the system. If you are concerned that your routine provides a different service or has the same signature as another, similarly named routine (that is, none of the arguments of your routine are of a data type defined in your DataBlade module), consider renaming the routine or qualifying its name with your three-character DataBlade module prefix. Doing so helps avoid conflicts in the system and confusion among your users.
Say, for example, that you are creating the OtherMap DataBlade module with a routine named Overlaps() that provides a different service than the Overlaps() routine supplied by the SimpleMap DataBlade module. In addition, your Overlaps() routine takes polygon data types not defined in the OtherMap DataBlade module. If the three-character prefix of your DataBlade module is OTH, then you might define your routine as follows:
However, if your Overlaps() routine takes arguments of data types defined in the OtherMap DataBlade module, you might define Overlaps() as follows:
Taking Advantage of Polymorphism
Informix Dynamic Server supports polymorphism; thus, you can have multiple routines with the same name that take different argument types. For example, a C programmer might be tempted to create routines named:
and:
These functions return the larger of their arguments. However, in SQL it is better to define the routines as follows:
and:
Limiting the Number of Arguments
To help your users remember how to use your DataBlade module routines, limit the number of arguments they take. Reevaluate any routines that take more than three arguments; such routines can become unwieldy or can inadvertently become modal (defined in the next section).
Avoiding Modal Routines
When you create DataBlade module routines, avoid including arguments that make them modal; that is, the mode of the routine changes depending on the third argument. For example, there are a number of different ways to call a routine that computes containment of spatial values. The SimpleMap DataBlade module might implement the following routine:
This routine determines whether the first polygon contains the second polygon, or whether the second contains the first. The caller supplies an integer argument (for example, 1 or 0) to identify which value to compute; but the purpose of this argument is not immediately evident to a new user of the DataBlade module.
Consider a second design for calculating containment, as follows:
This design is an improvement: not only are the routines nonmodal, the routine names also clearly explain what computation is performed.
|
