This document discusses polymorphism in PowerBuilder applications. Polymorphism allows the same method name to be used for different classes. Operational polymorphism uses the same method name for unrelated classes, while inclusional polymorphism uses inheritance and common ancestor classes. Inclusional polymorphism defines polymorphic methods in an ancestor class that descendant classes can optionally override or extend, allowing for generic messaging through the ancestor class. The document provides examples of implementing both operational and inclusional polymorphism using static and dynamic messaging.

1. Buliding Object-Oriented Applications in PowerBuilder Module 12 : Polymorphism

2. Objectives Describe operational and inclusional polymorphism Explain the different techniques to generically pass dynamic methods in messages Describe how to pass static methods in messages

3. Topics O verview of Polymorphism Operational Polymorphism Inclusional Polymorphism

4. Overview of Polymorphism The same method signature (name, arguments, and argument types) defined in different classes The behavior can be different Examples: cb_1.SetFocus( ) dw_1.SetFocus( )

5. Polymorphism The following messages all save changes, but use different method names: w_cust.of_SaveCust( ) w_invoice.of_SaveInvoice( ) w_order.of_SaveOrder( ) Using the same name would provide more consistency: w_cust.of_Save( ) w_invoice.of_Save( ) w_order.of_Save( )

6. Categories of Polymorphism Operational – Polymorphic methods for unrelated classes Must define methods for each appropriate class May require complex CHOOSE CASE construct or dynamic messaging Inclusional – Polymorphic methods implemented within class hierarchies

7. Operational Polymorphism Example *Note: there is no ancestor with of_Save() or ue_retrieve of_Save( ) ue_Retrieve w_ar_main of_Save( ) ue_Retrieve w_inv_main of_Save( ) ue_Retrieve w_ap_main

8. Operational Polymorphism Static Messaging For Example, the menuitem m_save script: string ls_classname w_ar_main lw_ar_main w_ap_main lw_ap_main ls_classname = ParentWindow.ClassName( ) CHOOSE CASE ls_classname CASE 'w_ar_main' lw_ar_main = ParentWindow // “cast” to correct class lw_ar_main.of_Save( ) CASE 'w_ap_main' lw_ar_main = ParentWindow // “cast” to correct class lw_ap_main.of_Save( ) ... CASE ELSE END CHOOSE

9. Operational Polymorphism Dynamic Messaging Example Messages are generic but with more overhead You don’t have to “cast” parentwindow to the appropriate type Bypasses compiler checking ParentWindow.DYNAMIC of_Save( ) ParentWindow.Event DYNAMIC ue_Retrieve( )

10. Inclusional Polymorphism Example Common user-defined ancestor Code in answer can be empty (virtual functions) Methods defined in ancestor; descendants can optionally override or extend of_Save( ) ue_Retrieve w_ar_main ue_Retrieve w_inv_main of_Save( ) w_ap_main of_Save( ) ue_Retrieve {w_main}

11. Inclusional Polymorphism Example The code in the menu would reassign ParentWindow reference to ancestor class: w_main lw_temp lw_temp = ParentWindow // “cast” to ancestor lw_temp.of_Save( ) lw_temp.EVENT ue_Retrieve( ) Enables generic static messaging Not required to define methods at descendent level – simply write the appropriate code for that descendent Requires the use of common ancestor class

12. Summary Polymorphism implies using the same method signatures for different object classes. Operational polymorphism is the use of the same method name in unrelated classes. Inclusional polymorphism makes use of inheritance hierarchies and common method names. An ancestor method can contain no defined behavior. A descendent class can extend or override ancestor behavior.

13. Summary Questions

14. Lab Setup What you will need to do in the lab: Define polymorphic functions

15. Lab Debriefing Define of_save( ) in the ancestor w_sheet

16. Lab Debriefing Redefine of_save at a descendent level

17. Lab Debriefing