Booa8 Slide 03


Published on

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Booa8 Slide 03

    1. 1. Buliding Object-Oriented Applications in PowerBuilder Module 3: Inheritance
    2. 2. Objectives <ul><li>Describe base, abstract, and concrete classes, and their roles in inheritance </li></ul><ul><li>Determine if an extension layer is necessary for your application </li></ul><ul><li>Compare and contrast a single-level hierarchy with a multiple-level hierarchy </li></ul><ul><li>Describe the two common methods of window inheritance: by style and by type </li></ul>
    3. 3. Topics <ul><li>Inheritance Basics </li></ul><ul><li>PowerBuilder System Classes </li></ul><ul><li>Inheritance Mechanics </li></ul><ul><li>Inheriting User-Defined Classes </li></ul><ul><li>Class Hierarchies </li></ul><ul><li>Building a Class Hierarchy </li></ul><ul><li>Frameworks and Class Libraries </li></ul><ul><li>Extension Layers </li></ul><ul><li>Hierarchy Levels </li></ul><ul><li>Style Versus Type Hierarchy </li></ul>
    4. 4. Inheritance <ul><li>Inheritance defines a relationship among classes wherein one class shares the structure or behavior defined in one or more classes. </li></ul>Grady Booch
    5. 5. Inheritance — Terminology <ul><li>In an inheritance relationship: </li></ul><ul><ul><li>Descendant – A class that inherits from another class, usually to extend or enhance the definition of another class; also called a subclass </li></ul></ul><ul><ul><li>Ancestor – A class whose definition is extended or enhanced by a descendant; also called a superclass </li></ul></ul><ul><ul><li>Subclassing – Creating new, descendent classes, forming a class hierarchy </li></ul></ul>
    6. 6. PowerBuilder System Classes <ul><li>PowerBuilder is built on a set of system classes </li></ul><ul><li>The system classes are used as ancestors for building subclasses with added behaviors and structures. </li></ul>
    7. 7. Try It - Browser <ul><li>Show Hierarchy from the browser. Examine w_master. </li></ul><ul><li>Note the functions you added in the previous lab are not inherited; but many other functions were </li></ul>
    8. 8. <ul><li>PowerBuilder system classes are the foundation for &quot;new&quot; classes </li></ul><ul><li>Examples: </li></ul><ul><li>Window w_customer </li></ul><ul><li>CommandButton cb_ok </li></ul><ul><li>Inheritance supported for windows, menus, and user objects </li></ul>Inheritance — PowerBuilder
    9. 9. Inheritance — &quot;New&quot; Classes <ul><li>When a class is defined, it includes: </li></ul><ul><ul><li>Name </li></ul></ul><ul><ul><li>Name of immediate ancestor class </li></ul></ul><ul><ul><li>Overridden property values </li></ul></ul><ul><ul><li>New properties and values (optional instance variables) </li></ul></ul><ul><ul><li>New methods (optional) </li></ul></ul>
    10. 10. <ul><li>Class definition for a &quot;New&quot; window: </li></ul><ul><ul><ul><li>$PBExportHeader$w_cust.srw </li></ul></ul></ul><ul><ul><ul><li>forward </li></ul></ul></ul><ul><ul><ul><li>global type w_cust FROM window </li></ul></ul></ul><ul><ul><ul><li>int X=673 </li></ul></ul></ul><ul><ul><ul><li>int Y=265 </li></ul></ul></ul><ul><ul><ul><li>int Width=1582 </li></ul></ul></ul><ul><ul><ul><li>int Height=993 </li></ul></ul></ul><ul><ul><ul><li>... </li></ul></ul></ul>Exported Syntax
    11. 11. Edit Source <ul><li>Source for any object may be displayed or edited from the System Tree. </li></ul>
    12. 12. Inheritance Mechanics (method 1) <ul><li>Click on the Inherit ToolBar Button </li></ul><ul><li>Select the object type from the dropdown </li></ul><ul><li>Select the object to inherit from </li></ul>
    13. 13. Inheritance — Mechanics (method 2) PowerBuilder New Feature
    14. 14. Syntax — Inherited Window <ul><li>forward </li></ul><ul><li>global type w_customer_listing_with_update from w_customer_list </li></ul><ul><li>end type </li></ul><ul><li>end forward </li></ul><ul><li>global type w_customer_listing_with_update from w_customer_list </li></ul><ul><li>end type </li></ul><ul><li>global w_customer_listing_with_update w_customer_listing_with_update </li></ul><ul><li>on w_customer_listing_with_update.create </li></ul><ul><li>call super::create </li></ul><ul><li>end on </li></ul><ul><li>on w_customer_listing_with_update.destroy </li></ul><ul><li>call super::destroy </li></ul><ul><li>end on </li></ul><ul><li>type dw_1 from w_customer_list`dw_1 within w_customer_listing_with_update </li></ul><ul><li>end type </li></ul><ul><li>… </li></ul>
    15. 15. Inheritance — Class Hierarchy <ul><li>A set of classes related by inheritance </li></ul><ul><li>Involves two or more levels of classes </li></ul><ul><li>Ancestor classes are general </li></ul><ul><li>Each descendent level is increasingly specific </li></ul><ul><li>PowerBuilder system classes are in a single-class hierarchy </li></ul>
    16. 16. PowerBuilder System Class Hierarchy
    17. 17. Building a Class Hierarchy <ul><li>To create a class hierarchy: </li></ul><ul><ul><li>Define common ancestor – Base class </li></ul></ul><ul><ul><li>Define windows as ancestors (descendants of base class) that are never &quot;opened&quot; – Abstract classes </li></ul></ul><ul><ul><li>Define descendants of abstract class windows that will be opened at execution time – Concrete classes </li></ul></ul>
    18. 18. User-Defined Class Hierarchy — Windows Abstract classes w_master w_detail Base classes w_main Concrete classes w_invoice w_customer w_lineitem w_order
    19. 19. Building a Class Hierarchy <ul><li>Base class: </li></ul><ul><ul><li>Direct descendant of a PowerBuilder system class </li></ul></ul><ul><ul><li>Never instantiated </li></ul></ul><ul><ul><li>Contains appearance common to all descendants (for example, company logo) </li></ul></ul>
    20. 20. Building a Class Hierarchy <ul><li>Abstract class: </li></ul><ul><ul><li>Defined to be used as an ancestor </li></ul></ul><ul><ul><li>Descendant of a base class </li></ul></ul><ul><ul><li>Never instantiated </li></ul></ul><ul><ul><li>Contains: </li></ul></ul><ul><ul><ul><li>Behavior common to all descendants </li></ul></ul></ul><ul><ul><ul><li>Data elements common to all descendants </li></ul></ul></ul><ul><ul><ul><li>Nested objects common to all descendants </li></ul></ul></ul>
    21. 21. Building a Class Hierarchy <ul><li>Abstraction: </li></ul><ul><ul><li>Focus on the essential aspects of a class </li></ul></ul><ul><ul><li>Discover similar behaviors in multiple peer classes </li></ul></ul><ul><ul><li>Code the behavior once in an ancestor class </li></ul></ul><ul><ul><li>Examine classes in an existing application </li></ul></ul><ul><ul><ul><li>What is common? </li></ul></ul></ul><ul><ul><ul><li>What can be abstracted? </li></ul></ul></ul>
    22. 22. Building a Class Hierarchy <ul><li>Abstract classes can have: </li></ul><ul><ul><li>Default property values </li></ul></ul><ul><ul><ul><li>Provide common &quot;look and feel&quot; </li></ul></ul></ul><ul><ul><ul><li>Examples: Background color, height, width </li></ul></ul></ul><ul><ul><li>Event scripts and functions — PowerBuilder and user-defined </li></ul></ul><ul><ul><ul><li>Provide common behavior </li></ul></ul></ul><ul><ul><ul><li>Examples: Open event and Close event scripts </li></ul></ul></ul><ul><ul><li>Additional instance variables (properties) </li></ul></ul>
    23. 23. Building a Class Hierarchy <ul><li>Concrete class: </li></ul><ul><ul><li>Descendant of an abstract class </li></ul></ul><ul><ul><li>Gets instantiated </li></ul></ul><ul><ul><li>Contains: </li></ul></ul><ul><ul><ul><li>Behavior specific to an application </li></ul></ul></ul><ul><ul><ul><li>Extends behavior of an abstract class </li></ul></ul></ul><ul><ul><ul><li>Additional controls (sometimes) </li></ul></ul></ul>
    24. 24. <ul><li>w_ap_main and w_ar_main are concrete classes </li></ul>Building a Class Hierarchy Abstract class {w_main} Concrete classes w_ap_main w_ar_main
    25. 25. Building a Class Hierarchy <ul><li>Naming classes </li></ul><ul><li>Differentiate among base, abstract, and concrete </li></ul><ul><ul><li>Library comments </li></ul></ul><ul><ul><li>Naming conventions </li></ul></ul><ul><ul><li>Placement in PBLs </li></ul></ul><ul><li>Examples: </li></ul><ul><ul><li>w_anc_ xxx //Base class </li></ul></ul><ul><ul><li>w_ xxx //Abstract (extension) class </li></ul></ul><ul><ul><li>w_aaa_ xxx //Concrete (application-specific) class </li></ul></ul>
    26. 26. Inheritance — Class Hierarchies <ul><li>Frameworks and class libraries: </li></ul><ul><ul><li>Class hierarchies or portions thereof can be reusable </li></ul></ul><ul><ul><li>Reusable portions can be called class libraries </li></ul></ul><ul><ul><li>Class hierarchies can work together </li></ul></ul><ul><ul><li>Class hierarchies can have dependencies </li></ul></ul><ul><ul><li>Dependent classes are called frameworks </li></ul></ul><ul><ul><li>Can purchase frameworks and class libraries to use as foundation classes </li></ul></ul>
    27. 27. Inheritance — Class Hierarchies <ul><li>Extension layers: </li></ul><ul><ul><li>Provide an insulating layer between abstract classes and concrete classes </li></ul></ul><ul><ul><li>Provide a layer for promoting common behavior to a common ancestor of multiple concrete classes without affecting other concrete classes </li></ul></ul>
    28. 28. <ul><li>Descendent windows (w_invoice and w_cust) are inherited from an ancestor window (w_main) </li></ul>Hierarchy Design Issue Abstract class {w_main} Concrete classes w_cust w_invoice
    29. 29. Hierarchy Design Issue <ul><li>Common code that should be in an ancestor for one group of descendants may be inappropriate for other descendants: </li></ul>Abstract class Concrete classes {w_main} w_cust of_Resize( ) w_invoice of_Resize( ) w_response
    30. 30. Extension Layer <ul><li>Common code promoted without affecting the common abstract ancestor class: </li></ul>Abstract classes {w_main} Concrete classes {w_app_main} of Resize( ) {w_app_resp} w_cust w_invoice w_response
    31. 31. Extension Layers and Frameworks <ul><li>Crucial when working with frameworks </li></ul><ul><li>Provide a place to define project-level methods and properties </li></ul><ul><li>Provide a means to extend base classes without affecting them </li></ul><ul><li>Unaffected by maintenance releases to base classes </li></ul><ul><li>Allow multiple projects to share a common framework, components, or base classes </li></ul>
    32. 32. Hierarchy Levels <ul><li>Descriptive terms for hierarchies: </li></ul><ul><ul><li>Shallow — Few levels of inheritance </li></ul></ul><ul><ul><li>Deep — Many levels of inheritance </li></ul></ul><ul><ul><li>Wide or broad — Many classes in a level </li></ul></ul><ul><ul><li>Narrow — Few classes in a level </li></ul></ul>
    33. 33. Hierarchy Levels No Base Class <ul><li>A single-level hierarchy: </li></ul>Power Builder system class Abstract classes {window} {w_sheet} {w_popup} {w_child}
    34. 34. Hierarchy Levels No Base Class <ul><li>Advantages: </li></ul><ul><ul><li>Easy to decide the class from which to inherit </li></ul></ul><ul><ul><li>Easy to create an extension layer </li></ul></ul><ul><li>Disadvantages: </li></ul><ul><ul><li>Can lead to &quot;over-engineered&quot; classes </li></ul></ul><ul><ul><li>May provide more functionality than needed </li></ul></ul><ul><ul><li>Can lead to redundant code </li></ul></ul><ul><ul><li>Potential performance implications </li></ul></ul><ul><ul><li>Ancestor scripts may be overly complex to maintain </li></ul></ul>
    35. 35. <ul><li>All classes in hierarchy have a common user-defined base class: </li></ul>Hierarchy Levels — Common Base Power Builder system class {window}
    36. 36. Hierarchy Levels — Common Base <ul><li>A common ancestor is inherited from a PowerBuilder system class: </li></ul>Abstract classes {w_main} Power Builder system class {window}
    37. 37. Hierarchy Levels — Common Base <ul><li>Next level is inherited from a base class: </li></ul>Power Builder system class Abstract classes {window} {w_sheet} {w_popup} {w_child} {w_main}
    38. 38. Hierarchy Levels — Common Base <ul><li>If a new function is needed for all the descendent classes, the function is declared once in a base class </li></ul>Power Builder system class Abstract classes {window} {w_sheet} {w_popup} {w_child} {w_main} of_Resize( )
    39. 39. Hierarchy Levels — Common Base <ul><li>Advantages: </li></ul><ul><ul><li>Provides class to promote all common properties and behaviors </li></ul></ul><ul><ul><li>Positions hierarchy for polymorphism (covered in later unit) </li></ul></ul><ul><li>Disadvantages: </li></ul><ul><ul><li>Difficult to identify appropriate ancestor </li></ul></ul><ul><ul><li>With extension layer, can double the number of layers </li></ul></ul>
    40. 40. Inheritance — Hierarchy Examples <ul><li>Two main approaches to window class hierarchies: </li></ul><ul><ul><li>Style-based </li></ul></ul><ul><ul><li>Type-based </li></ul></ul>
    41. 41. Window Ancestor — By Style <ul><li>Ancestor windows specific to a pattern </li></ul><ul><ul><li>For example, list / detail, master / detail </li></ul></ul><ul><li>Controls placed in the ancestor — DataWindows, CommandButtons, and so on </li></ul><ul><li>Communication between controls and window is &quot;hard wired&quot; </li></ul><ul><li>Note: InfoMaker is based on this &quot;forms&quot; concept </li></ul>
    42. 42. Example — By Style <ul><li>Two DataWindow controls are placed in the ancestor </li></ul><ul><li>Behaviors are provided for the window and the DataWindow controls </li></ul>
    43. 43. Window Ancestor — By Style <ul><li>Scripts are affected by adding a third DataWindow control: </li></ul>DoubleClicked! IF row>0 THEN dw_detail.Event ue_retrieve(row) END IF
    44. 44. Window Ancestor — By Style <ul><li>Advantages: </li></ul><ul><ul><li>Ancestor windows are specific to a pattern </li></ul></ul><ul><ul><li>Easy to use — typically only the DataWindow object and title are changed </li></ul></ul><ul><ul><li>Good for rapid prototyping </li></ul></ul>
    45. 45. Window Ancestor — By Style <ul><li>Disadvantages: </li></ul><ul><ul><li>Very specific to the pattern — inflexible to changes </li></ul></ul><ul><ul><li>Cannot add functions and properties to controls in the descendant </li></ul></ul><ul><ul><li>Adding controls to the descendant may require substantial overriding and recoding </li></ul></ul>
    46. 46. Window Ancestor — By Type <ul><li>An ancestor is created for each type of window </li></ul><ul><ul><li>Examples: w_sheet, w_response, w_popup </li></ul></ul><ul><li>Controls are not placed in the ancestor (except command buttons in w_response) </li></ul><ul><li>Each class has behavior and properties unique to the type of window </li></ul><ul><li>Components (windows and controls) are assembled in concrete classes </li></ul>
    47. 47. Window Ancestor — By Type {u_dw} {w_sheet} Abstract classes Concrete classes dw_list dw_detail {w_list_detail}
    48. 48. Window Ancestor — By Type <ul><li>Advantages: </li></ul><ul><ul><li>Design is flexible </li></ul></ul><ul><ul><li>Design relies on window and control ancestors being encapsulated and robust </li></ul></ul><ul><ul><li>Direct extension of PowerBuilder class metaphor </li></ul></ul>
    49. 49. Window Ancestor — By Type <ul><li>Disadvantages: </li></ul><ul><ul><li>Controls must be subclassed — more work upfront </li></ul></ul><ul><ul><li>Coding must be more generic (abstract) — more work upfront </li></ul></ul><ul><ul><li>Coding can be redundant as patterns show up in the application </li></ul></ul><ul><ul><li>Are these really disadvantages? It just requires planning and analysis first! </li></ul></ul>
    50. 50. Window Hierarchy — By Type PowerBuilder system class Abstract classes {window} {w_anc_main} Type is main {w_anc_popup} {w_anc_sheet} {w_anc_child} {w_anc_response}
    51. 51. Summary <ul><li>Inheritance is a relationship between objects in which the descendant incorporates the definition of the ancestor in its own definition. </li></ul><ul><li>Developer-defined classes are inherited from PowerBuilder system classes. </li></ul><ul><li>Class hierarchies consist of base, abstract, and concrete classes. </li></ul>
    52. 52. Summary <ul><li>Extension layers are layers of inheritance to which common code can be promoted without affecting the ancestor class. </li></ul><ul><li>A hierarchy with no common base is simple to use but can preclude code promotion (reuse). </li></ul><ul><li>A multiple-layer hierarchy with a common base class is more complex to use but allows code reuse. </li></ul>
    53. 53. Summary <ul><li>Style hierarchies preassemble objects into component packages. </li></ul><ul><li>Type hierarchies code abstract functionality into classes. Assembly occurs at the concrete level. </li></ul>
    54. 54. Summary Questions
    55. 55. Lab Setup <ul><li>What you will need to do the lab: </li></ul><ul><ul><li>Create a window class hierarchy </li></ul></ul><ul><ul><li>Use the Browser </li></ul></ul><ul><ul><li>Run the application </li></ul></ul>
    56. 56. Lab Debriefing <ul><li>What windows went into the Foundation PBL? </li></ul><ul><li>What windows went into the Extension PBL? </li></ul><ul><li>Why do you have these levels? Why not just a Foundation? </li></ul>