Object-Oriented Extensions to the 4GL Pat Bonser Product Readiness PUG Norway Lillehammer March 16th...

Object-Oriented Extensions to the 4GL

Pat BonserProduct Readiness

PUG Norway

Lillehammer

March 16th & 17th

© 2006 Progress Software Corporation2March 2006, PUG Norway

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.

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.


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


Object-orientation and the 4GL

OO Extensions to the 4GL• Not a replacement for existing code constructs

Not a migration requirement Can co-exist/integrate with procedural 4GL You do not need to use OO if you do not want to Use for natural benefits

• Strong typing

• SOA Interface

Goals of the OO Extensions to the 4GL

Phased Release: OpenEdge 10.1A is the first release for OO


OO terminology for familiar concepts• Classes, types, data members, methods & 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

Object-Oriented Concepts Overview

What do you need to understand before you use OO?


Object-oriented Terminology

A class is a structure that consists of:• A set of data definitions (data members)• A set of operations that maintain that data (methods)• Similar to definitions + procedures within a .p

A class’ data is stored in data members• Each data member is defined by name & type

A method is an operation within a class• To invoke a method, you send a message to an object• Similar to calling a subroutine or procedure within a .p

An object is an instance of a class• Created at runtime• Contains values within the data members

What are classes, data members, methods & objects?


Object-oriented Programming

How to start?• You need a model

– White-board models are okay! • 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


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


The Logical Model

Business Processing

Presentation Layer

Integration Data Access


Business Abstraction

What is an Order? Business Operations

• Approve

• Ship

• Check Inventory

Data Operations• Create

• Read

• Update

• Delete

Order


Higher Level Abstraction

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

Business

Entity


Encapsulation - Overview

A class encapsulates• Data members

• The methods that maintain them

Encapsulation of a class enforced via different access levels:

Qualifier Can access..

- private only from within the class itself

# protected only from within the class hierarchy

+ public from inside or outside the class hierarchy

Data & behavior are grouped together within a class


Benefits of Encapsulation

Why should I use encapsulation?

Objects are insulated from each other’s implementation detail & changes• Code is easier to maintain & evolve

Allows you to “black-box” data and functionality• Makes it easier to understand code

• Results in a more intuitive model

• Modular code


Type – <package>.<class>

Methods

Data Members

OOABL.BusinessEntity

# daObject:IDataAccess

+ lcBEXMLDataSet:LONGCHAR

+ fetchWhere():VOID

+ saveChanges():VOID

Data Members• daObject - Retrieve records• lcBEXMLDataSet - Stores records in XML to pass

Methods• fetchWhere - Select Records (Read)• saveChanges - Saves Changes (Create, Update, Delete)

What does a Business Entity need to do for the application?

Note: This example does not contain Security or Auditing

Super Class – Business Entity


Type Overview

Each class represents a new data type• Can be used as variables, parameters, return types

Allows for strong-typing • Early binding - types determined at compile time

• Type-consistency enforced at compile time and runtime

Type-name is the <package>.<classname>

A type is a new data type definition


Types – An Example

OOABL.BusinessEntity OOABL.beOrder

• Subtype of OOABL. BusinessEntity OOABL.beCustomer

• Subtype of OO4ABL.BusinessEntity

A subtype can appear

anywhere

a super type is expected


OOABL.beOrder OOABL.beCustomer

is a is a


Benefits of Types

Compile time checking for type consistency

Results in safer, bug-free code because all code paths checked at compile time

Strong Typing

myBEOrder = mybeExternalOrder. must be subtype

myBEOrder:fetchWhere() validates signature

MyBEOrder:lcBEXMLDataSet = “<?xml version="1.0"?>...”

validates data type


Inheritance Hierarchy Overview

Re-using and extending code

Inheritance is used to abstract out common functionality & data amongst similar classes

Inheritance relationship means a subclass inherits all data members & methods from a super class

Resulting subclass may extend or change behavior by overriding methods of super class or add functionality by adding new methods to the subclass


Inheritance - An Example


# daObject: IDataAccess


+ fetchWhere():VOID


Inherits

super class

subclass

Additional

Override

OOABL.BEOrder

# dsOrder: dataset

+ BEOrder ()

+ fetchWhere():VOID


+processOrder():VOID

Additional


Benefits of Inheritance

Why should I use inheritance?

Code is more re-usable• Common data members and methods abstracted

out of similar object types into a super class

Code is more generic• Operations that work on super classes will also

work on subclasses

• Subclasses can extend or replace behavior of super class


Delegation Overview

Letting contained classes do their own work

Delegation may be used when an object is built from other objects• The class hierarchy

Containing object forwards messages it can’t handle to a contained object, called its delegate

Containing object defines a “stub” for the message


Delegation – An Example

OOABL.BEOrder

# dsOrder: dataset

+ BEOrder ()

+ fetchWhere():VOID



OOABL.DAOrder

- dsOrder: handle

+ convertToDS():VOID

+ convertToXML():VOID

+ setcWhere():VOID

+ getcWhere():CHAR

+ setDataSources():VOID

+ selectRecords():LONGCHAR

+ updateRecords():VOID

+ setCallbacks():VOID

+ postOlineFill():VOID

+ postDataSetFill():VOID

Business entity object delegates the record retrieval to data access object

delegates


Benefits of Delegation

Why should I use delegation?

Simplifies Code• More modular

Run-time flexibility since delegate could easily be changed on-the-fly• Results in a sort of “dynamic” inheritance

Can provide a stable public API for less-stable or multiple APIs of delegate classes


Interfaces Overview

Implementing a standard set of methods

An interface specifies a set of methods which must be implemented by a class in order to claim support for the interface

Similar to inheritance, except no default data to inherit & no default implementation for the methods• i.e., no clear common behavior or data can be

represented

A class may implement zero or more interfaces


Interface – An Example

OOABL.dataObject

# xmlDataSet: LONGCHAR

# hDataSet:HANDLE

# cWhere:CHARACTER

# DataObject()

+ convertToDS():VOID

+ convertToXML():VOID

+ setcWhere():VOID

+ getcWhere():CHAR

+ setDataSource():VOID



<interface>

OOABL.IDataAccess

+ setcWhere():VOID

+ getcWhere():CHAR

+ setDataSource():VOID



implements


Benefits of Interfaces

Code is more generic• Operations that work on interface classes will also

work on classes that implement it

• Each subclass will have its own implementation of the methods within the interface resulting in polymorphism

Allows you to specify a standard, required interface• Implementation of common methods required for

a particular class type are enforced by the interface mechanism

Why should I use interfaces?


Polymorphism Overview

Treating similar objects generically

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


Polymorphism – An Example

OOABL.BEExternalOrder

- InvoiceNum:INTEGER

+ processOrder():VOID

- sendInvoiceInfo():VOID

- startSession():VOID

OOABL.BEInternalOrder

-crossChargeDeptNum:INTEGER


- getCrossChargeDept():CHAR

-setCrossChargeDept():VOID

- crossCharge():VOID

OOABL.BEOrder

# dsOrder: dataset

+ BEOrder ()

+ fetchWhere():VOID




Benefits of Private Methods

OOABL.BEExternalOrder

- InvoiceNum:INTEGER

+ processOrder():VOID

- sendInvoiceInfo():VOID

- startSession():VOID

Hmm... I’d like to change the invoicing backend. I can make this change to private methods without effecting the public APIs.


OO Concepts Overview Summary

Now you are familiar with concepts needed for OOABL:

OO terminology for familiar concepts• Classes, types, data members, methods & 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


OO in the 10.1A Features

CLASS definitions .cls files Single inheritance hierarchies Data members and methods Interfaces Polymorphism Delegation CAST function VALID-OBJECT() method Support with development tools


Similarities between Classes and Procedures

Classes Procedures

Class files (.cls) Procedure files (.p)

Data members Define variables

VOID methods Internal procedures

Other methods User defined functions

Constructor Code in main block

Inheritance Super-procedures.p.cls


Positioning

When should 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 an application, or different appls• Need to adhere to Interfaces

When are Procedures best?• Tasks• Processes• Workflows• Dynamic or late bound code (not strong typed)• Disposable programs

Differences between Classes and Procedures


Interoperability – Classes and Procedures

Classes• Can RUN a procedure• Can invoke internal procedure / UDF using

procedure handle

Procedures • Can NEW a CLASS• Can DELETE an object• Invoke methods using object reference• Can pass object reference as a parameter


The Shortest Path To Using A Class

Defining a class• Class construct

– Data members– Constructor– Destructor– Methods

Using a class• Defining a variable as

a user defined type

• Instantiating an object

• Accessing class data members

• Invoking class methods

• Deleting an instance

Just the basics


CLASS Statement

CLASS :

END [ CLASS ].

Syntax

type-name

Example – OOABL/Example.clsCLASS OOABL.Example:

END.

Rules for type-name on next slide


CLASS statement – Type Name

Type NameSpecify a user-defined type name for a class, a super class, or an

interface as a character string

• Package– A character string that specifies a period-separated list of components that,

along with class-name, uniquely identify the – Each component maps to a directory level in the path and each forward or

backward slash separator in the path is replaced with a period (.)– Any package specification must remain constant between compile time and

run time

• Class-name– A character string that specifies a class– Must match the name of a class file (excluding its .cls or .r extension) that

contains the definition for the defined class– Must be located in the relative path represented by package

[package.]class-name

SyntaxMust be in the

PROPATH


Programming Conventions for Classes

All class names should use camel case• For example

– Example.cls

Keywords should not be used for class names, method names or data member names• Some keywords are marked illegal by the compiler

Classes should be put into packages, possibly using your company name• For example, built-in classes provided by Progress

– Progress.Lang– In these examples OOABL is the package


Class Members - Data Members

CLASS type-name:

[ data member …]

[ constructor ]

[ destructor ]

[ method … ]

END [ CLASS ].

Class members

Syntax

Example – OOABL/Example.clsDEFINE PUBLIC VARIABLE cPublic AS CHARACTER

INITIAL "I'm PUBLIC" NO-UNDO.DEFINE PROTECTED VARIABLE cProtected AS CHARACTER

INITIAL "I'm PROTECTED" NO-UNDO.DEFINE PRIVATE VARIABLE cPrivate AS CHARACTER

INITIAL "I'm PRIVATE" NO-UNDO.


Defining a Class: CONSTRUCTOR Rules

Name the same as class name• Without the package

Default access level is PUBLIC• Can’t be PRIVATE

Accepts parameters Allows you to add custom code Has no return type Only one per class

Special method used when instantiating the class


Class Members - CONSTRUCTOR

CONSTRUCTOR { PUBLIC | PROTECTED }

class-name ( [param [,param] …] ):

/* constructor body */

END [CONSTRUCTOR].

Can NOT be PRIVATESyntax

Example – OOABL/Example.cls

CONSTRUCTOR PUBLIC Example (): MESSAGE "This is the constructor for Example.cls" VIEW-AS ALERT-BOX INFO BUTTONS OK.END CONSTRUCTOR.

Must match class name


Defining a Class: DESTRUCTOR Overview

Never called directly• DELETE OBJECT statement

Class instances are NOT automatically deleted• Responsibility of the developer

Used to free resources when a class is deleted Provided by OpenEdge unless explicitly defined Always PUBLIC Never has parameters or return-value Same name as class name

• No package


Class Members - DESTRUCTOR

DESTRUCTOR PUBLIC class-name ( ):

/* destructor-body */

END [DESTRUCTOR].

Syntax

Example – OOABL/Example.cls

DESTRUCTOR PUBLIC Example (): MESSAGE "This is the destructor for Example.cls" VIEW-AS ALERT-BOX INFO BUTTONS OK.END DESTRUCTOR.

Must match class name


Class Members - METHOD Overview

Define the behavior of a class All behavior implemented within methods

• No logic outside of methods Methods can be PUBLIC, PROTECTED or

PRIVATE Must have a return-type, or VOID Can accept parameters

• Same syntax as UDFs FINAL methods cannot be overidden


Class Members - METHOD – Syntax/Example

METHOD {method-modifiers} {VOID | return-type} method-name

( [param [, param] …] ):

/* method body */

END [METHOD].

Syntax

Example – OOABL/Example.clsMETHOD PUBLIC CHARACTER getcPrivate(): MESSAGE "In getcPrivate" VIEW-AS ALERT-BOX INFO BUTTONS OK. RETURN cPrivate.END.

METHOD PUBLIC VOID setcPrivate(INPUT cValue AS CHARACTER): MESSAGE "In setcPrivate" VIEW-AS ALERT-BOX INFO BUTTONS OK.

ASSIGN cPrivate = cValue.END.


Code Sample – Defining a Class

CLASS OOABL.Example:DEFINE PUBLIC VARIABLE cPublic AS CHARACTER INITIAL "I'm PUBLIC" NO-UNDO.DEFINE PROTECTED VARIABLE cProtected AS CHARACTER INITIAL "I'm PROTECTED" NO-UNDO.DEFINE PRIVATE VARIABLE cPrivate AS CHARACTER INITIAL "I'm PRIVATE" NO-UNDO.CONSTRUCTOR PUBLIC Example (): MESSAGE "This is the constructor for Example.cls" VIEW-AS ALERT-BOX INFO BUTTONS OK.END CONSTRUCTOR.METHOD PUBLIC CHARACTER getcPrivate(): MESSAGE "In getcPrivate" VIEW-AS ALERT-BOX INFO BUTTONS OK. RETURN cPrivate.END. METHOD PUBLIC VOID setcPrivate(INPUT cValue AS CHARACTER): MESSAGE "In setcPrivate" VIEW-AS ALERT-BOX INFO BUTTONS OK. ASSIGN cPrivate = cValue.END. DESTRUCTOR PUBLIC Example(): MESSAGE "This is the destructor for Example.cls" VIEW-AS ALERT-BOX INFO BUTTONS OK.END DESTRUCTOR.END CLASS.


Class Hierarchies

Classes provide single inheritance• Allows extending of super classes

• Inherit non-private data members and methods

Hierarchy is any number of levels Top level is root class

• Implicitly inherits only from Progress.Lang.Object


Defining a Class INHERITS Option

Understanding INHERITS

Identifies a super class that this class extends• Provides access to non-private data members

and methods of the super class

Super-type-name • Identifies the super class

• Must be locatable


Example:

OOABLExample.cls

& Example2.cls

CLASS OOABL.Example:END CLASS.

CLASS OOABL.Example2 INHERITS OOABL.Example:

END CLASS.

is a

CLASS

[INHERITS super-type-name ]:

[ <class-members> …]

END [ CLASS ].

Syntax

Defining a Class INHERITS Option


Inheritance – Complete Class Hierarchy


# daObject: IDataAccess


+ fetchWhere():VOID


Inherits

super class

subclass

Additional

Override

OOABL.BEOrder

# dsOrder: dataset

+ LabBEOrder () CONSTRUCTOR

+ LabBEOrder () DESTRUCTOR

+ fetchWhere():VOID



Additional


The Shortest Path To Using A Class

Defining a class• Class

– Data members– Constructor– Destructor– Methods

Using a class• Defining a variable as a

user defined type

• Instantiating an object

• Accessing class data members

• Invoking class methods

• Deleting an instance

Just the basics


Defining a Variable as a User Defined Type

Supports strong typing of class references A data type for classes and interfaces Similar to a HANDLE variable Cannot be used in an array or database

SyntaxDEFINE [access-mode] VARIABLE object-reference

AS [ CLASS ] type-name.

Example – OOABL/Basic.pDEFINE VARIABLE myExampleObject AS CLASS OOABL.Example NO-UNDO.


Defining a Variable as a User Defined Type

Methods, procedures and UDF’s support classes as parameters

Always passed by reference• Only object reference is copied

Limitations

Note with OpenEdge 10.1A cannot be passed across AppServer boundaries


Instantiating an Object Using NEW

Syntax

obj-reference = NEW type-name ([<parameter>[,…]])

[ NO-ERROR ].

Example – OO4GLExt/Basics.p

/* Instantiating an object using NEW statement */ myExampleObject = NEW OOABL.Example().


Instantiating an Object Using NEW

From a class or procedure Locates the named class

• Uses package and class name

Creates a new instance of the class • An “object” or “class instance”

Invokes the constructors in the class hierarchy Must be accessible at compile time

The NEW statement – instantiates a class


Using a Class: CONSTRUCTOR Rules

Using• Invoking the class runs the constructor

• Constructors invoke other constructors in the class hierarchy

• Cannot be directly called from a method

Special method used when instantiating the class


Use an object reference

Accessing PUBLIC Data Members

Example– OOABL/Basic.p

Syntax

obj-reference:data-member-name

MESSAGE "Access a PUBLIC variable. The value is…" myExampleObject:cPUBLIC

VIEW-AS ALERT-BOX INFO BUTTONS OK.


Invoking PUBLIC Methods

Use PUBLIC get or set methods to access

Accessing PRIVATE & PROTECTED Data Members

cVar = myExampleObject:getcPrivate().

Example – OOABL/Basic.p

Syntax[ <return-value> = ] obj-reference:method-name

( [<parameter> [,<parameter>]… ] )


Deleting an Instance

Invokes the class instance destructors• From bottom of hierarchy upwards

Frees all memory allocated to an object Otherwise

• Resources stay allocated• Destructor NEVER run

May not be deleted immediately• If class instance still on execution call stack

The DELETE OBJECT statement


Deleting a Class Instance

DELETE OBJECT object-reference [NO-ERROR].

Syntax

Example– Basic.p

DELETE OBJECT myExampleObject.ASSIGN myExampleObject = ?. /* prevents accidental use later */

A DESTRUCTOR will not be invoked if you do not explicitly DELETE OBJECT


Considerations

PUBLIC only variables and PROTECTED data members scoped to enclosing class

If you forget to delete a class that has a temp-table it will cause a memory leak in the temp table db as well as the class itself

Scoping


Considerations

Two – pass compiler Compile time validation of object reference Validates

• Methods

• Parameters

Compiles all files in class hierarchy

Compiler changes


Current Class Limitations

Limited support for reflection No dynamic run (call) support No support for PUBLISH / SUBSCRIBE Cannot expose a class as a Web service Cannot ProxyGen a class Limited native error handling support Cannot NEW a class over an AppServer boundary

Considerations


Migrating from Procedures to Classes . . . Remove AppBuilder generated code Convert procedures and functions to methods Move code from main block to constructor Identify PUBLIC, PRIVATE, PROTECTED methods Define interfaces Change handles to object references Convert super procedure stack to class hierarchy Remove handle references, e.g.

• THIS-PROCEDURE, TARGET-PROCEDURE, SESSION:FIRST-PROCEDURE, etc.

Considerations


. . . Migrating from Procedures to Classes Convert SHARED to PROTECTED

Change RUN to NEW

Change internal methods references to new colon syntax

Review error handling• Remove RETURN and RETURN ERROR

statements

Remove PUBLISH and SUBSCRIBE statements Remove references to protected super class

temp-tables from subclasses

Considerations


Object-Oriented Extensions to the 4GL

Summary & Questions

“… have been designed to complement the 4GL, and are meant to be combined

and integrated with ‘traditional’ procedures,

when it makes sense to do so. The object-oriented

enhancements extend the core values of the 4GL, not

replace them.”


Example of More Detailed Logical Model

Super Class

Subclass

Inheritance

DelegationPolymorphism

Interface

Public

Private

Protected

Data Members

Methods

Polymorphism

Date post:	29-Dec-2015
Category:	Documents
Upload:	geraldine-shaw
View:	216 times
Download:	1 times

Object-Oriented Extensions to the 4GL Pat Bonser Product Readiness PUG Norway Lillehammer March 16th...

Documents