Other techniques

PowerBuilder allows you to implement a wide variety of object-oriented techniques. This section discusses selected techniques and relates them to PowerBuilder.

In function overloading, the descendent function (or an identically named function in the same object) has different arguments or argument datatypes. PowerBuilder determines which version of a function to execute, based on the arguments and argument datatypes specified in the function call:

Instantiate the appropriate object at runtime, as shown in the following code example:

// This code works with both dynamic and
// static lookup.
// Assume these instance variables
u_platform iuo_platform
Environment ienv_env
...
GetEnvironment(ienv_env)
choose case ienv_env.ostype
   case windows!
      iuo_platform = CREATE u_platform_win
   case windowsnt!
      iuo_platform = CREATE u_platform_win
   case else
      iuo_platform = CREATE u_platform_unix
end choose

Although dynamic lookup provides flexibility, it also slows performance.

When using static lookup, you must define default implementations for functions in the ancestor. These ancestor functions return an error value (for example, -1) and are overridden in at least one of the descendent objects.

By defining default implementations for functions in the ancestor object, you get platform independence as well as the performance benefit of static lookup.

Delegation occurs when objects offload processing to other objects.

For example, you might create a service object that handles extended row selection in DataWindow objects. In this case, your DataWindow objects contain code in the Clicked event to call the row selection object.

1. Create a service object (u_sort_dw in this example).

2. Create an instance variable (also called a reference variable) in the owner (a DataWindow control in this example):

   u_sort_dw iuo_sort
   

3. Add code in the owner object to create the service object:

   iuo_sort = CREATE u_sort_dw
   

4. Add code to the owner’s system events or user events to call service object events or functions. This example contains the code you might place in a ue_sort user event in the DataWindow control:

   IF IsValid(iuo_sort) THEN
      Return iuo_sort.uf_sort()
   ELSE
      Return -1
   END IF
   

5. Add code to call the owner object’s user events. For example, you might create a CommandButton or Edit>Sort menu item that calls the ue_sort user event on the DataWindow control.

6. Add code to the owner object’s Destructor event to destroy the service object:

   IF IsValid(iuo_sort) THEN
      DESTROY iuo_sort
   END IF
   

For example, you might create a string-handling service that can be enabled by any of your application’s objects.

The steps you use to implement objects in an associative relationship are the same as for aggregate relationships.

When you enable a user object’s AutoInstantiate property, PowerBuilder instantiates the user object along with the object, event, or function in which it is declared. You can also declare instance variables for a user object. By combining these two capabilities, you create user objects that function as structures. The advantages of creating this type of user object are that you can:

• Create descendent objects and extend them.

• Create functions to access the structure all at once.

• Use access modifiers to limit access to certain instance variables.

1. Create the user object, defining instance variables only.

2. Enable the user object’s AutoInstantiate property by checking AutoInstantiate on the General property page.

3. Declare the user object as a variable in objects, functions, or events as appropriate.

   PowerBuilder creates the user object when the object, event, or function is created and destroys it when the object is destroyed or the event or function ends.

Many applications use a DataWindow visual user object instead of the standard DataWindow window control. This allows you to standardize error checking and other, application-specific DataWindow behavior. The u_dwstandard DataWindow visual user object found in the tutorial library TUTOR_PB.PBL provides an example of such an object.

Since DataStores function as nonvisual DataWindow controls, many of the same application and consistency requirements apply to DataStores as to DataWindow controls. Consider creating a DataStore standard class user object to implement error checking and application-specific behavior for DataStores.