Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Booa8 Slide 03


Published on

Published in: Business
  • Be the first to comment

  • Be the first to like this

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>