Object-oriented programming with OpenEdge® 10.1A

1. Object-oriented programming with OpenEdge® 10.1A PSDN Web Seminar February 2006 Salvador Viñals Consultant Product Manager Progress Software – OpenEdge Division

2. Audience • Technical level: Intermediate • This session is targeted to customers somewhat familiar with object-orientation • This session does not focus on reference information

3. OpenEdge 10.1A Focus Improve the productivity of OpenEdge … to provide our partners significant competitive advantage through the software they develop and deploy

4. OpenEdge 10.1A Highlights What we are not going to talk about today… • OpenEdge Architect • Auditing • Language: short-hand syntax (::), READ-XML(), WRITE-XML(), BY-REFERENCE, XP manifests, 64bit r-code • RDBMS: performance, more online utilities and schema changes • JDBC Type 4 • Symbiotic Adapter for SonicMQ® • Install: Simpler, faster and embeddable • Rebranding: Fathom to OpenEdge • Replication: Enable online, AI, single command failback • DVD • Linux 64bit (RH AS 3, SuSe 9) …. and much more

5. Agenda • Object-orientation in OpenEdge 10.1A • Benefits • Positioning • Concepts and Features • Object-oriented programming • Where to go next

6. Introducing OO in 10.1A OpenEdge® 10.1 introduces formal object-oriented programming through language extensions that support user-defined classes. User-defined classes allow you to define objects, with methods and data, and interfaces for building business applications.

7. Benefits Object-orientation Benefits • Let’s you organize applications the way you think: • around objects • Increase application robustness (strong typing) • More development productivity with encapsulation, inheritance, and polymorphism • Promotes reusability • Helps you build OERA. More closely support SOA • Modular. Components. Composite applications. • Service contracts = Interfaces • Ease application maintenance • Natural integration with: • modeling tools • other OO platforms • Ease hire new developers

8. Positioning • When shall you consider using Classes? • For well defined and designed functional units • Not too coarse. Not too granular. • Useful (and easy) when called from at least three different modules of the application, or different applications • Need to adhere to Interfaces • When Procedures are best? • Tasks • Processes • Workflows • Dynamic or late bound code (not strong typed) • Disposable programs

9. Quick facts • Multiple rollout strategy: OpenEdge 10.1A is the first one • The object-oriented extensions do not replace existing language constructs • You do not need to use OO if you do not want • Classes can include ON <event> constructs • 10.1A language compiler is two-pass

10. InteroperabilityProcedures and Classes • Procedures • Can NEW a CLASS • Can DELETE an object • Invoke methods using object reference • Can pass object reference as a parameter • Classes • Can RUN a procedure • Can invoke internal procedure / UDF using procedure handle

11. Similarities betweenClasses and Procedures .p .cls

12. Object-Oriented Concepts Overview What do you need to understand to use OO? • OO terminology for familiar concepts • Classes, data members, methods, types & objects • Encapsulation • Grouping data & behavior together • Inheritance • Re-using and extending code • Delegation • Letting contained objects do their own work • Interfaces • Implementing a standard set of methods • Polymorphism • Generic code for objects with common data & behavior

13. OO in the 10.1A Features • CLASS definitions • Single inheritance hierarchies • Data members and methods • Interfaces • Polymorphism • Delegation • CAST function • VALID-OBJECT() method • .cls files • Support with development tools

14. Details on Object-Oriented Concepts Overview and 10.1A Features • Refer to the following 10.1A Beta program presentations that will be made available on PSDN along with this Web seminar: • (beta) Object-oriented programming in the Progress 4GL 10 1A1B Webinar.ppt • (beta) Object-oriented programming in the Progress 4GL 10 1A2B Webinar.ppt

15. Agenda • Object-orientation in OpenEdge 10.1A • Benefits • Positioning • Concepts and Features • Object-oriented programming • Where to go next

16. Object-oriented programming • When shall you consider using Classes? • For well defined and designed functional units • Not too coarse. Not too granular. • Useful (and easy) when called from at least three different modules of the application, or different applications • Need to adhere to Interfaces • How to start? • You need a model (white-board models are good) • Best not to start with the presentation layer • Best not to start with the data management layer • Start inside-out: • Model the required functionality • Identify potential functional units candidates for classes

17. Object-oriented programming • Logical model - Abstraction • Identify Classes. Data members. Methods. • Identify inheritance “chains” • Identify interfaces you need to conform to • Identify where you’ll need delegation, polymorphism, etc. • Refine: Too coarse? Too fine grained? Will you use it? • Implementation model • Define each of above • Refine as needed • Start programming

18. Object-oriented programming • Logical model - Abstraction • Identify Classes. Data members. Methods. • Identify inheritance “chains” • Identify interfaces you need to conform to • Identify where you’ll need delegation, polymorphism, etc. • Refine: Too coarse? Too fine grained? Reusable? • Implementation model • Define each of above • Refine as needed • Start programming

19. Business Abstraction Order • What is an Order? • Business Operations • Approve • Ship • Check Inventory • Data Operations • Create • Read • Update • Delete

20. Higher Level Abstraction Business Entity • What is a Business Entity • Tracks my business • What do I do with a business entity • Business Operation • Security • Auditing • Delegate CRUD to Data Access in subclasses • Create • Read • Update • Delete

21. Example of Logical Model Business Processing Presentation Layer Data Access Integration

22. Example of More Detailed Logical Model Data Members Super Class Protected Methods Interface Inheritance Private Subclass Public Polymorphism Delegation Polymorphism

23. Object-oriented programming • Logical model - Abstraction • Identify Classes. Data members. Methods. • Identify inheritance “chains” • Identify interfaces you need to conform to • Identify where you’ll need delegation, polymorphism, etc. • Refine: Too coarse? Too fine grained? Reusable? • Implementation model • Define each of above • Refine as needed • Start programming

24. Super Class – Business Entity OOABL.BusinessEntity # daObject:IDataAccess # lcBEXMLDataSet:LONGCHAR + fetchWhere():VOID + saveChanges():VOID Type – <package>.<class> Data Members Methods What does a Business Entity need to do for the application? • Data Members • daObject - Retrieve records • lcBEXMLDataSet – Stores records in XML to pass around • Methods • fetchWhere –Select Records (Read) • saveChanges –Saves Changes (Create, Update, Delete) • Note: Example doesn’t contain Security or Auditing but that could be defined here as well

25. Super Class – Business Entity CLASS OOABL.BusinessEntity: /* data members */ DEFINE PUBLIC VARIABLE lcBEXMLDataSet AS LONGCHAR NO-UNDO. /* methods */ METHOD PUBLIC LONGCHAR fetchWhere (INPUT cBEWhere AS CHAR): END. /* fetchWhere*/ METHOD PUBLIC VOID saveChanges (): END. /* saveChanges */ END CLASS. /*BusinessEntity Class*/

26. Inheritance Hierarchy Overview Re-using and extending code • Inheritance is used to abstract out common functionality & data amongst similar classes • Inheritance relationship means a sub-class inherits all data members & methods from a super class • Resulting sub-class may extend or change behavior by overriding methods of super classor add functionality by adding new methods to the sub-class

27. OOABL.BusinessEntity # daObject: IDataAccess # lcBEXMLDataSet:LONGCHAR + fetchWhere():VOID + saveChanges():VOID OOABL.BEOrder # dsOrder: dataset + BEOrder ():VOID + fetchWhere():VOID + saveChanges():VOID + processOrder():VOID Inheritance - An Example super class Inherits subclass Additional Override Additional

28. Inheritance - An Example CLASS OOABL.BEOrder INHERITS OOABL.BusinessEntity: {ProDataSet/PrivateOrderTT.i} {ProDataSet/PrivateDSOrder.i} CONSTRUCTOR PUBLIC BEOrder (OUTPUT lSuccess AS LOGICAL): END CONSTRUCTOR. /* constructor BEOrder */ DESTRUCTOR PUBLIC BEOrder (): END DESTRUCTOR. /* destructor BEOrder */ METHOD PUBLIC OVERRIDE LONGCHAR fetchWhere (INPUT cBEWhere AS CHAR): END. /* fetchWhere*/ METHOD PUBLIC OVERRIDE VOID saveChanges(): END. /* saveChanges */ METHOD PUBLIC VOID processOrder(): END. /* processOrder */ END CLASS. /*BEOrder Class*/

29. Delegation Overview Letting contained classes do their own work • Delegation may be used when an object is built from other objects that are not in the class hierarchy • The containing object forwards messages it can’t handle to a contained object, called its delegate • The containing object defines a “stub” for the message

30. OOABL.DAOrder - dsOrder: handle + convertToDS():VOID + convertToXML():VOID + setcWhere():VOID + getcWhere():CHAR + setDataSources():VOID + selectRecords():LONGCHAR + updateRecords():VOID + setCallbacks():VOID + postOlineFill():VOID + postDataSetFill():VOID OOABL.BEOrder # dsOrder: dataset + BEOrder ():VOID + fetchWhere():VOID + saveChanges():VOID + processOrder():VOID Delegation – An Example Business entity object delegates the record retrieval to data access object delegates

31. OOABL.DAOrder - dsOrder: handle + selectRecords():VOID OOABL.DataObject # xmlDataSet # DataObject() CONSTRUCTOR /* methods from interface */ + selectRecords():VOID <interface> OOABL.IDataAccess + selectRecords():VOID OOABL.BusinessEntity # daObject:OOABLIDataAccess #lcBEXMLDataSet:LONGCHAR + fetchWhere():VOID OOABL.BEOrder # dsOrder: dataset BEOrder() CONSTRUCTOR BEOrder() DESTRUCTOR + fetchWhere():VOID inherits Delegation - Using an Interface to Ensure an API Animation walks through the code design… OrderMain.p /* Defines a BEOrder variable */ /* NEWs BEOrder */ /* calls BEOrder fetchWhere */ /* Passes dataset back to UI */ implements delegates Delegate Class Container Class

32. Delegation – An Example (complete sample code in annotations) CLASS OOABL.DAOrder INHERITS OOABL.DataObject: {ProDataSet/PrivateOrderTT.i} {ProDataSet/PrivateDSOrder.i} CONSTRUCTOR PUBLIC DAOrder (): END CONSTRUCTOR. /** INHERITED METHODS OVERRIDE SECTION **/ METHOD PUBLIC OVERRIDE VOID ConvertToDS (): /* Uses default READ-XML behavior */ DATASET dsOrder:READ-XML ("LONGCHAR", lcXMLDATASET, "EMPTY", ?, ?, ?). END. /*END ConvertToDS */ METHOD PUBLIC OVERRIDE VOID ConvertToXML(): /* Default XML-WRITE to LONGCHAR */ DATASET dsOrder:WRITE-XML ("LONGCHAR", /* target-type */ lcXMLDATASET, /* longchar */ TRUE, /* formatted */ ?, /* encoding */ ?, /* schema location */ ?, /* write schema */ ?). /* minschema */ END. /* end of ConvertToXML */ . . . / . . .

33. Delegation – An Example (complete sample code in annotations) . . . / . . . METHOD PUBLIC OVERRIDE LONGCHAR selectRecords (): DEFINE VARIABLE hdsOrder AS HANDLE NO-UNDO. DEFINE VARIABLE hEvents AS HANDLE NO-UNDO. DEFINE VARIABLE iBuff AS INTEGER NO-UNDO. DEFINE VARIABLE hBuff AS HANDLE NO-UNDO. DEFINE QUERY qOrder FOR Sports2000.Order, Sports2000.Customer, Sports2000.SalesRep. DEFINE DATA-SOURCE srcOrder FOR QUERY qOrder Order KEYS (OrderNum), Customer KEYS (CustNum), SalesRep KEYS (SalesRep). DEFINE DATA-SOURCE srcOline FOR OrderLine. hdsOrder = DATASET dsOrder:HANDLE. /* Use NEW SET-CALLBACK Method for THIS-OBJECT instead of persistent proc */ SetCallBacks(INPUT hdsOrder). /* Prepare the query */ QUERY qOrder:QUERY-PREPARE("FOR EACH Order WHERE order.ordernum = " + (cWhere) + ", FIRST Customer OF Order, FIRST SalesRep OUTER-JOIN OF Order"). /* Attach datasources before fill */ BUFFER ttOrder:ATTACH-DATA-SOURCE(DATA-SOURCE srcOrder:HANDLE, "Customer.Name,CustName"). BUFFER ttOline:ATTACH-DATA-SOURCE(DATA-SOURCE srcOline:HANDLE). hDSOrder:FILL(). /*Detach datasources after fill */ DO iBuff = 1 TO DATASET dsOrder:NUM-BUFFERS: DATASET dsOrder:GET-BUFFER-HANDLE(iBuff):DETACH-DATA-SOURCE(). END. convertToXML(). RETURN lcXMLDataSet. END. /* selectRecords */ . . . / . . .

34. Interfaces Overview Implementing a standard set of methods • An interface specifies a set of method prototypes which must be implemented by a class in order to claim support for the interface • Reliably defines a common API supported by different classes • Use an INTERFACE to ensure the API exists • Similar to inheritance, except no default data to inherit & no default implementation for the methods • A class may implement zero or moreinterfaces

35. <interface> OOABL.IDataAccess + setcWhere():VOID + getcWhere():CHAR + setDataSource():VOID + selectRecords():LONGCHAR + updateRecords():VOID implements Interface – An Example OOABL.dataObject # xmlDataSet: LONGCHAR # hDataSet:HANDLE # cWhere:CHARACTER # DataObject() + convertToDS():VOID + convertToXML():VOID + setcWhere():VOID + getcWhere():CHAR + setDataSource():VOID + selectRecords():LONGCHAR + updateRecords():VOID

36. Interface – An Example (all dataObject classes will implement this interface) INTERFACE OOABL.IDataAccess: METHOD PUBLIC VOID setcWhere(INPUT icWhere AS CHARACTER). /* will set the where clause for record selection */ METHOD PUBLIC CHAR getcWhere (). /* will get the where clause for record selection */ METHOD PUBLIC VOID setDataSources(INPUT cDataSources AS CHARACTER). /*will initialize the dataset's datasources */ METHOD PUBLIC LONGCHAR selectRecords(). /* will select object specific records */ METHOD PUBLIC VOID updateRecords(INPUT lcXML AS LONGCHAR). /* store create, updates, and deletes to records */ METHOD PUBLIC VOID convertToDS (). METHOD PUBLIC VOID convertToXML (). END INTERFACE. /*IDataAccess */

37. Polymorphism Overview Treating similar objects generically • Multiple classes can inherit from same super class • Each can override behavior in super class • Multiple implementations • Different behavior • Instances of classes derived from the same super class can be dealt with generically at runtime • A message in the super class is dispatched to the corresponding method in a subclass • Polymorphism means each subclass may respond to the same message in a different manner

38. OOABL.BEOrder # dsOrder: dataset + BEOrder ():VOID + fetchWhere():VOID + saveChanges():VOID + processOrder():VOID • OOABL.BEInternalOrder • crossChargeDeptNum:INTEGER • + processOrder():VOID • getCrossChargeDept():CHAR • setCrossChargeDept():VOID • - crossCharge():VOID • OOABL.BEExternalOrder • InvoiceNum:INTEGER • + processOrder():VOID • sendInvoiceInfo():VOID • - startSession():VOID Polymorphism – An Example

39. Polymorphism – An Example (complete sample code in annotations) CLASS OOABL.BEOrder INHERITS OOABL.BusinessEntity: . . . CLASS OOABL.BEExternalOrder INHERITS OOABL.BEOrder FINAL: . . . CLASS OOABL.BEInternalOrder INHERITS OOABL.BEOrder FINAL: . . . /* ProcessOrderMain.p -- Main procedure for an Order Dataset */ DEFINE INPUT PARAMETER lInternal AS LOGICAL NO-UNDO. DEFINE INPUT PARAMETER piOrderNum AS INTEGER NO-UNDO. DEFINE OUTPUT PARAMETER lProcessed AS LOGICAL NO-UNDO. DEFINE VARIABLE myBEOrder AS CLASS OOABL.BEOrder NO-UNDO. DEFINE VARIABLE lcXML AS LONGCHAR NO-UNDO. DEFINE VARIABLE lSuccess AS LOGICAL NO-UNDO. /* Instantiate the right subclass */ IF lInternal THEN myBEOrder = NEW OOABL.BEInternalOrder(OUTPUT LSuccess). ELSE myBEOrder = NEW OOABL.BEExternalOrder(OUTPUT lSuccess). /* fetch the right order and orderlines */ lcXML = myBEOrder:fetchWhere(STRING(piOrderNum)). myBEOrder:processOrder(OUTPUT lProcessed). DELETE OBJECT myBEOrder.

40. <interface> OOABL.IJobTask + setcTask():VOID + getcTask():CHARACTER + completeTask:LOGICAL OOABL.Worker - cTask:CHARACTER /* methods from interface */ + setcTask():VOID + getcTask():CHARACTER + completeTask:LOGICAL OOABL.Boss # MyWorkerObject: Worker + Boss() CONSTRUCTOR + Boss() DESTRUCTOR + delegateTask():LOGICAL + AnnounceResults():VOID polymorphism OOABL.RegionalManager + AnnounceResults():VOID OOABL.CorporateManager + AnnounceResults():VOID Polymorphism – Another Example Director.p /* Defines a Boss variable */ /* NEWs Boss (RegionalManager or CorporateManager */ /* sets Boss’ cTaskToDelegate */ /* calls Boss’ delegateTask */ /* deletes Boss object etc. */ delegates implements

41. Where to go next … Product Documentation • OpenEdge Getting Started: Object-oriented Programming • What's New in OpenEdge 10.1: Object Oriented Programming (April 2006) • Article: Object-orientation and the Progress® ABL in OpenEdge® Release 10.1A • Development patterns web papers (coming up soon) Education Course PSDN

42. Thank you for your time!

43. Questions