Other techniques – PB Docs 80

Other techniques

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

Using function overloading

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

ltoop160.gif

Dynamic versus static lookup

Dynamic lookup In certain situations, such as when insulating your application
from cross-platform dependencies, you create separate descendent objects,
each intended for a particular situation. Your application calls
the platform-dependent functions dynamically:

ltoop200.gif

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

While dynamic lookup provides flexibility, it also slows performance.

Static lookup To ensure fast performance, static lookup is a better option. However, PowerBuilder enables
object access using the reference variable’s data type
(not the data type specified in a CREATE statement):

ltoop180.gif

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:

ltoop140.gif

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

Using delegation

Delegation occurs when objects offload processing to other
objects.

Aggregate relationship In an aggregate relationship (sometimes called a whole-part
relationship

), an object (called an owner object) associates
itself with a service object designed specifically for that object
type.

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.

proc.gif To use objects in an aggregate relationship:

  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):

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

  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:

  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:

Associative relationship In an associative relationship, an object associates itself
with a service to perform a specific type of processing.

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.

Using user objects as structures

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

proc.gif To create a user object to be used as a structure:

  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.

Subclassing DataStores

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.


Document get from Powerbuilder help
Thank you for watching.
Was this article helpful?
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x