Object Oriented Programming

Transcription

1 Partners in Success Object Oriented Programming Object Oriented ProvideX or OOPs We've Done it Again Presented by: Mike King Copyright 2002 Best Software Canada Ltd. All rights reserved. No part of this publication may be reproduced, or transmitted in any form or by any means, electronic, mechanical, photocopied, recorded or other, without prior written consent of Best Software Canada Ltd. 1

2 Overview What is an Object? (The Layman's View) Why Use an Object? OOP Terminology ProvideX OOP Interface What's New in Version 5.1? How do Objects Work? When to Use OOP and When Not To The ProvideX OLE Server Sample Objects This session is designed to provide an intensive look at the Object Oriented Programming (OOP) capabilities of ProvideX and to introduce the ProvideX OLE Server. We will discuss creating ProvideX objects and how to use the OLE server to invoke these from external packages. The following topics will be covered: General OOP Concepts How to envision OOP - A 3GL view of objects The buzz words and what they mean ProvideX OOP Interface Review of OOP directives and their use Recent enhancements to OOP Directives Technical Overview of OOP How OOP actually works Performance considerations Error Handling OLE Server ProvideX.Script and how to use it Naming conventions Installing OLE server Sample Objects 2

3 What is an Object? Fundamentally, an object is a single unit consisting of: Data referred to as properties. Functions referred to as methods. An object is referenced by its identifier. All access to an object is through the identifier. It is all you need to use an object. The identifier is often referred to as a handle. Rather than look at an "object" from a theoretical perspective, let's look at it from a more practical perspective. Basically, an object consolidates both code and data into a single unit. This single unit can then be used within an application to simplify design, coding, and testing. All references to an object is done through the object identifier. This identifier is fundamentally a pointer or index to that object. Applications cannot directly access any of the data, but must go through the object identifier. Visualization of a Typical Object: Data: Object Identifier Name$, Addr$, City$ Functions: Add(), Delete(), Open() 3

4 What is an Object? An object has predefined characteristics. A class definition provides details of the object: Declares name, data, and functions. Defines all objects of the same type. Multiple objects can exist of the same class. Each object is referred to as an instance. Maintains its own data area. Shares functions. In order to use an object you must first define its characteristics the data and functions the object possesses. This is accomplished by defining what is referred to as an object class. A class definition provides details on what an object contains: its data (properties), functions (methods), and other characteristics (name, initialization code, wrapup code, etc.). Multiple objects can exist of the same class. For example, GL accounts might be serviced by two objects: one representing the credit side of a transaction, the other representing the debit side. These objects would have the same characteristics (as defined by the class) and share function definitions; however, each would have its own data region. Object Object Data (Properties) Functions (Methods) Data (Properties) In addition to maintaining data and function declarations, the class definition can define rules regarding the reading/writing of data elements and the logic to be performed during object creation and deletion. 4

5 What is an Object? An object is a function/subroutine library with static data. Functions define what an object can do. Functions may have local data that persists. Object elements can have common names. For example, consider Client and Vendor objects: Both could have a Delete function to delete their respective information. Both could have some common properties such as Name and Address. Each could have unique properties; e.g.,lastinvoice for Client, LastOrder for Vendor. One way to look at an object is as a subroutine library with static data. When you create an object, it contains a series of functions defining its capabilities. By referencing the object, you are in effect, selecting a function library and the associated data. Each object has a number of data elements or properties. Some of these properties are visible outside the object and some are only visible within the object. The names assigned to data and functions within the object are unique within the object; i.e, different objects can have data elements or functions of the same name. The names relate only to the object and not to anything else. This concept allows for the development of a common naming system. For example, you can have a wide variety of objects, each with their own Delete and Insert functions. This makes coding and standards much easier, since a designer can write guidelines for Delete and Insert functions that will be adhered to within a variety of objects. Common names for data elements can also be implemented an element name or description can exist in different elements but will relate only to the object it belongs to. 5

6 What is an Object? An object can be derived from another object. Classes can include other classes. Common functions/data would be defined once. A class can override functions/data. New functions can be selectively overridden. This allows for generic object definitions; e.g., Phone # object that validates phone numbers. GL Acct object that validates GL account numbers. This is referred to as inheritance. Often in systems design, some logic is similar across a variety of modules; e.g., the validation for a telephone number or GL account might be identical throughout the system. Objects implement this functionality by allowing classes to include definitions from other classes. When one class includes another class (or classes), it inherits all of its data elements (properties) and functions (methods). For example, a Client object has a variety of properties and functions to control client information on the system. Since a distributor is also a client, a Distributor object would have all the properties and functions of the Client object but would likely require some additional attributes or changed functionality. It is also possible to create Objects to be used as the building blocks of an application. For example, you might create a GL Acct object that contains not only the account number, but all the functions for validating the account number format, looking up the account number, splitting the account number into component pieces, etc. The GL Acct object can then be used in other objects whenever a programmer needs to incorporate the same logic and data. So, you only have to create the logic once. 6

7 Why Use an Object? Consistency in Design and Code Enables same 'functionality' throughout. Allows common function definition to exist in many different objects. Reduces programmer's learning curve. Data Protection Controls external access because data is kept within the object. Avoids accidental misuse of values. Provides ability to do run-time data validations. There are a number of good reasons to use objects. Generally, objects make application development quicker and easier; and, they enforce modularity, which makes ongoing enhancements simpler. Consistency Consistency is one of the major reasons for using objects. By taking advantage of the fact that a common function name, such as Delete, can exist in similar but different objects, programmers can learn the basics of an application quicker. For example, if there is a Delete function for all objects that relate to data information throughout the application design (Client, Vendor, Product, etc.), then the programmer only ever has to remember to use Delete to remove these items. The object itself worries about whether all the conditions are met to allow for the removal. Also, a common property (e.g.,inactive) can be provided for consistent testing of the different conditions of a Client versus a Vendor versus a Product. This allows programmers to write generic object-related routines such as: Function PurgeHistory( ObjId ) ObjId'Start() while GetNext( ObjId ) if ObjId'Inactive then ObjId'Delete () wend return 1 This code works with virtually all objects to purge inactive information from the system provided the object has Start, GetNext, and Delete functions and an InActive property. Continued 7

8 Why Use an Object? (Continued) Data Protection Certain data elements (properties) can be created that will be visible only while running within the object. These are considered local or static elements they are particularly useful for maintaining critical information (internal reference pointers, etc.) that is controlled solely by the object and is not directly accessible to outside code. An example of this would be a field in a file that contains a linked list pointer. To avoid the issue of programs accidentally corrupting the pointer, you could make this data internal to the object only and declare it local or static. You may want some data elements to be accessible from outside the object yet be able to control all access to them. These are considered properties. Access to properties can be controlled within the object. The object definition and logic decides which properties the user can read and update. For example, a field such as Salary could be restricted to users that rightfully have access to the data. This capability can also be used to make sure that data content is correct. For example, a Date field could have update logic applied to it so that only valid dates are placed into a file. 8

9 Why Use an Object? Better Control/Separation of Code Re-uses common functions to: Reduce duplication of code. Simplify code maintainability. Create a smaller footprint. Access from Outside the Application Provides integration via COM. Self-contained objects can be used by outside applications. Applications can be distributed via DCOM. Control/Separation of Code Another underlying advantage that objects give us is the ability to re-use common application code. OOP provides this advantage in two ways: First, common object-related functions can be developed functions that take advantage of the fact that an object is self-contained and need not concern themselves with the object's particulars. For example, the PurgeHistory function (page 7) can be used on any object provided the object has Start, GetNext, InActive, and Delete properties/methods. This allows the code to be used in multiple places within the application, reduces duplication, and minimizes the chance of introducing errors. Second, inheritance can be applied objects that utilize code and concepts from other objects. This further reduces code duplication, reduces errors, and makes for a smaller and tighter application. Objects themselves can used as subroutine/function libraries, which enables code to written once and used in numerous places within the system. Access from Outside the Application If you design objects that are fundamentally self-contained, they can be used by outside applications (via the ProvideX OLE Server). It is possible to create a ProvideX object, then invoke it from other languages such as VB, VBScript, Delphi, and C++. The ProvideX OLE Server allows virtually any object to be invoked by, and directly interact with, outside application development environments. You can use DCOM to invoke ProvideX objects remotely. 9

10 Object Oriented Programming Terminology Encapsulation An object is self-contained and may contain other objects. Inheritance An object may be (and usually is) derived from another object; e.g., A Distributor is a Client is a Company. Polymorphism Similar objects may share/redefine common properties and methods. Lets take a moment to look at the terminology that represents the three generally accepted main concepts of OOP: Encapsulation Well designed objects are self-contained; i.e., they internalize, as much as possible, the logic and data required to fulfill the purpose of the object. They do not rely on external influences. For example, a good object that is being used to control client file access would not expose its file channel nor refer to a variable element that is not directly contained within the object. This provides the maximum in terms of flexible design (when using objects). Inheritance Inheritance acknowledges the fact that an object may be derived from another similar object. For example, the name and address information of a company could be defined and maintained by a Company object. This object could then be inherited by a Client object that extends the core functionality of Company to include client-related information. The Client object could be further inherited by a Distributor object to include distributor-related information, such as quotas. Polymorphism Many objects share functions and/or properties that may behave differently internally but still have a common purpose. For example, the Delete function for a Client object has the same purpose as a Delete function for a Product object, but it would likely do very different things. Polymorphism acknowledges this concept and allows the programmer to simply refer to the function Delete while the system determines exactly what Delete should do based on the type of object. In the case of a client, it may check outstanding balances for a product, it may check for invoice file references, inventory on hand, etc. 10

11 OOP Terminology Encapsulation Company Properties: Methods: Name Address City PhoneNumber FaxNumber Add Delete Find Fax The following is an example of Encapsulation using the object Company. The Company object has the properties: Name, Address, City, PhoneNumber, and FaxNumber. It has the methods: Add, Delete, Find, and Fax. This is how the world sees the properties and methods of Company. Likely, there are many more functions and data within the object code, but these are the only aspects of Company that we wish to provide to applications external to the object itself. For example, the Find function accesses a file, locates a company's information, and makes the information accessible as Company properties. Find encapsulates all of the logic and other aspects involved in finding the company's information, which may entail using file numbers, record formatting logic, etc. All that is visible from the Company object are the properties and methods relating to the object. Other particulars relating to the object are self-contained in the object definition. One very obvious advantage of encapsulation is that it allows designers to alter the underlying structures and logic without having to alter applications that use the object (as long as the methods and properties still perform the same logical function). For example, if the file to be accessed by Find changes (perhaps PhoneNumber comes from a different file), only the object definition would need to be changed. The programs that use this object would be oblivious to the change. 11

12 OOP Terminology Inheritance & Polymorphism Company Properties: Name Address Methods: Add, Delete, Edit Customer Properties: Limit LastInvDate Methods: Invoice, Delete Supplier Properties: MinOrder LeadTime Methods: Order, Delete Let's take the previous example one step further and consider the use of Inheritance and Polymorphism. The Company object describes a business entity. Typically, an application might have two main types of business entities to deal with: customers and suppliers. While both of these entities are considered "companies", each represents a slightly different view of the Company object. The Customer entity has properties dealing with the orders placed, such as credit limit and last invoice date. The Supplier entity includes a different set of properties, such as delivery lead time and minimum order amount. However, both still maintain the characteristics of a "company". Inheritance allows an object to take on the characteristics and functionality of a similar object. Although the Customer and Supplier objects contain some unique attributes, their common attributes are inherited from Company. In OOP, Polymorphism represents the ability to redefine inherited functionality within an object. For example, Company, Customer, and Supplier have a function named Delete although the function name may be identical in each object, Delete may be used differently depending on the properties within the object. By simply having a reference to the object and naming the functions consistently, we can invoke functions regardless of the type of the object. The application does not need to know the object type in order determine how to delete the object. By definition, the object knows how to delete itself. 12

13 ProvideX OOP Interface ProvideX OOP Directives DEF CLASS Defines the object class. PROPERTY Declares data/properties. LOCAL Declares private data/properties. FUNCTION Declares methods. LIKE Declares inherited class. PROGRAM Declares default programs. PRECISION* Declares precision. STATIC* Dynamically declares LOCAL variables. DROP Deletes an object. ProvideX OOP Functions NEW ( ) Creates an object instance. REF ( ) Controls reference counts. * New for Version 5.1. ProvideX uses a combination of directives and functions to control the definition, creation, and deletion of objects. The ProvideX OOP directives used to define objects are explained on pages 14 to 23. The NEW ( ) function (for creating an object) and the REF ( ) function (for controlling access to an object or deleting one) are discussed later in the presentation. Regarding object memory management, ProvideX is designed to do most of the housekeeping required to implement objects. Generally, applications only have to request that a new instance of an object be created and ProvideX locates and load its definition. When the object is no longer needed (its reference count reaches zero) the object and all its properties are released. Class definitions are handled similarly. Unless specifically defined, ProvideX will dynamically load the definition of an object class and maintain it in memory until there are no references to it (either by an Object or another Class inheriting it). 13

14 Defining a Class The DEF CLASS Directive Defines an object class. Declares properties (data) and methods (functions) to be associated with an object. Object is created based on class structure. Object is referenced by an identifier which provides access to the class structure. Object identifier is stored in a numeric variable. Within ProvideX, objects are defined through the use of classes. The class defines the name given to the object definition (such as Company, Customer, or Supplier) as well as the object's properties and methods. The DEF CLASS directive allows the application to define an object. The definition includes: Object data/properties (both hidden and exposed). Object methods/functions. Objects whose characteristics are to be inherited. Programs and the related logic that supports the object. Once an object class has been defined, then it can be used to create objects using the NEW ( ) function which returns the object identifier. This function is described in more detail later in this presentation. 14

15 Defining a Class The DEF CLASS Directive DEF CLASS "name" CREATE label {REQUIRED} DELETE label {REQUIRED} Begins the definition of the object class. Specifies name used to define type of object. Name case and slash type are ignored. Allows control of object creation/deletion logic: CREATE allows override of ON_CREATE. DELETE allows override of ON_DELETE. REQUIRED forces logic to be executed. Normally, create/delete are not executed if inherited. Use REQUIRED to force execution when inherited. The DEF CLASS directive is used to declare the start of an object definition. It defines the name of the object and it can be used to override object creation and deletion logic. The name specified in the DEF CLASS directive provides the class name that will refer to this type of object. Class names are case-insensitive and forward/backward slashes are considered equivalent. Duplicate names are not allowed within the system. By default, an object can have ON_CREATE and/or ON_DELETE logic defined. This logic will be executed automatically when an object is created. If desired, you can change the default statement labels by specifying a new label name. Normally, object creation and deletion logic is invoked only when an object of this specific class is created/destroyed. That means, if you have ON_CREATE logic for an object A and object B inherits it, then the ON_CREATE for object A will not be executed. You can override this by including the keyword REQUIRED following the CREATE or DELETE clause. In this case, the creation and/or deletion logic is always executed. In terms of precedence, if an object inherits another object that has creation logic, the creation logic for the inherited object is performed first; e.g., if object C inherited object B which inherited object A, then the ON_CREATE in object A would be performed first, followed by object B's and finally object C's. Deletion logic is performed in the opposite order. 15

16 Defining a Class Class Definition Directives Definition of an object class: 0010 DEF CLASS "name" 0020 PROPERTY var, var, 0030 LOCAL var, var, 0040 FUNCTION method (param) 0050 LIKE "otherclass","otherclass ", 0060 PROGRAM "interface_prog" 0070 PRECISION nnn 0080 END DEF The DEF CLASS directive is followed immediately by the description of the object. The END DEF directive marks the end of the definition. The following class definition directives are described in detail later in this presentation: PROPERTY properties for the object. LOCAL internal properties for the object. FUNCTION functions/methods for the object. LIKE other objects that this object inherits from. PROGRAM default program that contains the object logic. PRECISION default program precision to be used while within object. 16

17 Defining a Class The PROPERTY Clause PROPERTY var, var, Declares accessible variables. May specify GET / SET procedures: PROPERTY name GET label label is called to return the value. = expression can be used to define calculation. PROPERTY name SET label label is called with value. May specify ERR instead of label to prevent access. Both can be given. The PROPERTY clause is used to declare the properties that can be accessed by the application program. These properties can be treated like any other variable in the system and are accessible using the Apostrophe operator. Example: Company'Name$ = "Willy Wonka" PRINT Company'Name$ Also, you can specify logic to be called automatically whenever a property is read or written. This capability allows the application designer to control how the underlying application will view and update any of the object properties. A property name can be followed by a GET label to define the location of the logic to call whenever the property is read in the application. With a GET in place, the specified logic issues a RETURN value which returns the actual value of the property to the application. If the logic resides outside of the defining program, then the name of the program and entry point can be provided in quotes instead. Example: PROPERTY ExtendedAmount GET Extension Extension: RETURN Quantity * Price Continued 17

18 PROPERTY Clause (Continued) To intercept all of the property updates, you can specify SET label. With a SET in place, the system calls the logic whenever the property is being updated and passes it the value being set. Like the GET option, an external program/entry point can be provided. Example: Using an external program, PROPERTY Quantity SET "Invline;ChgQty" Where Invline contains: 2000 ChgQty: 2010 ENTER NewQty 2020 IF NewQty = Quantity then RETURN 2030!.. Update inventory.then RETURN If the logic is within the defining program, then you would simply specify the statement label. Example: PROPERTY Quantity SET ChgQty To prevent the user from being able to GET or SET a property, specify the keyword ERR following the GET/SET declaration. Example: PROPERTY ExtendedAmount GET Extension SET ERR An error exit within the GET/SET causes the error to be returned to the application. If the logic required to do a read is simply a formula, then it can be inserted directly in the PROPERTY definition clause. Example: PROPERTY ExtendedAmount = Quantity*Price In this case, any attempt to SET this property outside of the object itself would result in an error. If you have a property that contains an object identifier to another object, then you can specify the keyword OBJECT following the property name. When the object is deleted, ProvideX will use the REF function against this object identifier to remove it, as long as it has no other references. Example: DEF CLASS "Customer" PROPERTY File OBJECT When you delete an object whose class is Customer, then the system reduces the reference count of the object whose identifier is in File and, if it is no longer being referenced, deletes it as well. 18

19 Defining a Class The LOCAL Clause LOCAL var, var, Declares data that is only visible to processing logic. Data fields are hidden while performing logic. Data is only accessible from within object procedures. The LOCAL clause is used to define the properties for an object class that are not exposed to external applications. They can be accessed during the execution of program logic only, such as GET/SET logic or methods that have been invoked by the system to deal with the object. Like the PROPERTY clause, the variable declarations on the LOCAL clause can include dimensioned arrays and object references as well. LOCAL properties are typcally used for: File handles (if the object is maintained on a file). Security information. Flags and status information used by the programming logic. 19

20 Defining a Class The FUNCTION Clause FUNCTION method (param) logic Declares method that the object can perform. Can include optional parameter list param. If specified, use to match with the format of caller. Allows for multiple definitions of functions. Calls the procedure named logic. Procedure should return a value. If no value is returned, then the system forces 0 or " ". The FUNCTION clause is used to declare a method for an object. Each method needs to have associated logic that will be called when it is invoked. Example: FUNCTION Find(X$) LookupCust LookupCust: ENTER Cst_id$! Logic to find the client RETURN sts! Return value indicates success Alternatively, the function logic can directly follow the FUNCTION declaration. Example: FUNCTION Find(X$) ENTER Cst_id$! Logic to find the client RETURN sts! Return value indicates success. FUNCTION END Every method should return a value. The value can take the form of a string or numeric value depending on the name associated to the function (string functions must end with $). If no RETURN value is specified, then the system will return a value of zero for numeric functions and "" (null) for string functions. As a general rule of thumb, methods should return a non-zero value when successfully executed. This allows for logic such as: IF NOT(Cst'Find("ABCD")) THEN GOTO Bad_cust. Continued 20

21 FUNCTION Clause (Continued) Function parameters are not required and the variable names used are for documentation purposes only. If parameters are provided, then the type and number must match the parameters that the application code provides. Multiple definitions of the same method name can be specified, as long as each method has a different parameter list. In order to determine which method to actually use, ProvideX attempts to match up the parameter lists specified with the parameter lists provided in the application. Examples: In the class definition, FUNCTION Find(X$) LookupByName FUNCTION Find(X) LookupByNumber LookupByName: ENTER Cst_id$! Logic to find the client by name RETURN LookupByNumber: ENTER Cst_id! Logic to find the client by number RETURN In the application, Cst'Find("ABCD") This calls LookupByName Cst'Find(1234) This calls LookupByNumber See Page 32 for information on enhancements to the FUNCTION clause for Version

22 Defining a Class The LIKE Clause LIKE "otherclass","otherclass", Inherits properties/methods defined in otherclass. Can inherit from multiple classes. Duplicate definitions result in the first occurrence taking precedence. Can redefine inherited properties/methods. Class can provide its own definition. The LIKE Clause is used to inherit the properties from one or more other classes. All properties and methods are inherited from the specified classes. When multiple occurrences of the same property/function are found within the inheritance, the first class declared in the LIKE directive takes precedence. Example: DEF CLASS "Company" FUNCTION Delete() REMOVE (fileno, KEY=COMP_ID$) RETURN 1 END DEF DEF CLASS "Client" FUNCTION Delete() IF AMT_OWING <> 0 RETURN 0 REMOVE (fileno, KEY=CUST_ID$) RETURN 1 END DEF DEF CLASS "Dealer" LIKE "Client", "Company" END DEF The Dealer class of objects would use the "Client" 'Delete() method, since it was declared first. 22

23 Defining a Class The PROGRAM Clause PROGRAM "interface_prog" Defines default program that services this class of object. Entry points can process methods and read/write properties. The following optional entry points are supported: ON_CREATE called when the object is created. ON_DELETE called when the object is deleted. If not specified, the program with the DEF CLASS is used. The PROGRAM clause is used to define the default program name that is going to service an object. This can be used to override the program which contains the DEF CLASS. If this clause is specified for an object class: Whenever an object is created, the system will attempt to call the specified program at the label ON_CREATE. Whenever an object of this class is deleted, the system will attempt to call the specified program at the label ON_DELETE. No error will be reported if the label does not exist. In addition, any references to program logic in a property read/write or a method definition can contain a leading semi-colon. For example, the following class definitions are effectively the same: PROGRAM "Cust" FUNCTION Find(X$) ";LookupByName" vs FUNCTION Find(X$) "Cust;LookupByName" 23

24 Deleting a Class DELETE CLASS "name" Deletes class definition and all related information. Allows class to be redefined. Can be done only when no objects exist for the class. Note: A START directive deletes all class definitions. Once a class definition is established, then it may not be changed but it can be deleted and recreated using the DELETE CLASS directive. Only class definitions that have no references to them may be deleted. This means that no class can be deleted when: Any object exists which refers to this class. Any other class exists which refers to this class by its LIKE clause. Any attempt to delete a class that has a reference to it will return an Error #50: "Class in use or already defined." All class definitions will be deleted when a START directive is issued. 24

25 Renaming a Class RENAME CLASS "name" TO "newname" Changes name of an existing class. Has no effect on existing objects. They continue to use original class definition. Once renamed, a new definition can be established for class. Allows for easy customization. The RENAME directive can be used to alter the name of a previously defined class. This functionality allows the application designer to alter an existing object class easily, without having to change programs. For example, if you had an existing application with a Product class object but needed to add a new field to the object, such as LOT_NUMBER: RENAME CLASS "Product" TO "Orig_Product" DEF CLASS "Product" LIKE "Orig_Product" PROPERTY LOT_NUMBER END DEF All subsequent uses of a Product class object would be identical now to the standard Product class and also have the property LOT_NUMBER. 25

26 Creating an Object NEW ("class") Creates new object. Returns object identifier. If class is not defined previously, ProvideX attempts to find DEF CLASS in the file class.pvc. This allows for fully dynamic class definitions. Causes execution of ON_CREATE logic. Note: Use REF() to increment reference count. The NEW ( ) function is used to create a new object based on a specified class name. If the class name already exists, then its definition is used. If class has not been defined previously, the system attempts to load the program class.pvc and execute/define the DEF CLASS within it. Note: The DEF CLASS directive must be at the start of the program. Example: Cst = NEW ("Customer") If the class definition for Customer does not already exist in memory, then the system attempts to load the program Customer.pvc. If this is successful, the NEW ( ) function will return the object identifier assigned to the object. If the system is unable to properly determine the class definition, an Error #54: "Unable to locate Object class definition" will be generated. If the label ON_CREATE exists in the class definition, it will be called to initialize the object. You can pass parameters to the NEW ( ) function following the class name as well. These parameters will be passed to the ON_CREATE entry point. Example: C = NEW("Customer", File_number) In Customer.pvx: 0010 ON_CREATE: ENTER File_no 26

27 Deleting an Object REF (DROP "obj_id") DELETE OBJECT Function Directive Performed using either approach. Executes ON_DELETE logic. Recovers memory associated with the object. Causes invalid object identifier after a destroy. Reference may be reused. Note: DROP OBJECT or DELETE OBJECT can be used. Every object created in the system has a reference count that, in conjunction with the REF ( ) function, can be used to simplify housekeeping. The system sets the reference count for any newly created object to one. If you plan to use an object in more than one place, then use REF (ADD obj_id) to increment the reference count. When finished with an object, use REF (DROP obj_id) to decrement the reference count. If the reference count becomes zero, then the object is deleted. REF (READ obj_id) returns the current reference count value. All calls to REF ( ) return the current reference count (or 0, if deleted). If you do not want to use the REF ( ) function to control an object, you can use the DELETE OBJECT directive to destroy the object. Only the objects whose reference count is 1 can be deleted. Once an object is destroyed, its identifier may be re-assigned to another object. You should no longer use the object identifier in your application, as it may reference a totally different object (if the identifier is re-assigned). All objects are destroyed when the application issues a START directive or if the END directive is entered at command mode. Note: Either DROP OBJECT or DELETE OBJECT directive can be used. 27

28 Program Logic You can associate program logic with an object. Object creation/deletion, property read/write, and functions. During execution, all properties become simple variables, including those declared LOCAL. The OBJ system variable contains the current object identifier. When executing program logic in response to an object method, property read/write, or during object creation/deletion, the system variable OBJ contains the object identifier relating to the object that you are processing. In addition, all properties, local and static data, become simple variables within your program. If you have a property called Name$ in your class definition, then the variable Name$ in your program will contain that value and it can be manipulated by your program logic directly. During the execution of the program logic, direct property manipulation (reading/writing) will not invoke any GET/SET logic. However, if you refer to a property using its object identifier, then the system will invoke the GET/SET logic. Example: DEF CLASS "Employee" PROPERTY PayRate GET CheckAuthority Internally, within the execution of the object program logic, any reference to PayRate will access the value in this property directly. However, _Obj'PayRate will invoke the CheckAuthority logic. 28

29 What's New in 5.1? UNIQUE Class Property Guarantees single instance of object of this class. All NEW ( ) calls return same object identifier. Increment REF count Avoids having to save identifier in global variable and test it. Provides for centralized processing. Ideal for common libraries; i.e, Security, File Open, Date Validation, Utilities. Use REQUIRED to force execution when inherited. Drops object after reference count goes to zero. In many applications, it may be desirable to limit an object to a single instance in memory. For example, an object that is essentially a subroutine library only one instance of this library is necessary. By adding the UNIQUE option to the DEF CLASS directive, you will be able to force a single instance of an object in memory. Any object declared as UNIQUE will have a single instance created, and any subsequent attempt to create an instance will simply return the same object identifier and increment the object reference count by one. Example: DEF CLASS "WindowsAPI" UNIQUE ON_CREATE REQUIRED This allows programs to use the NEW operator to logically create the object then DROP the object when done. The UNIQUE clause guarantees only a single instance of the object will ever exist. Another use of the an unique object could be a session or application control object that could have information such as the company codes, user information, operating date, etc. By declaring this object as unique, only one instance will ever be created and any application can access it. 29

30 What's New in 5.1? PRECISION and STATIC Directives PRECISION Clause Forces standard precision setting for object. If not used, object inherits default precision (normally 2, but based on PD parameter). Sets precision before each function. Restores precision upon exit from function. STATIC Clause Allows definition of variables that persist within object. In effect, allows dynamically-defined LOCAL variables. PRECISION Directive By default, an object is invoked using the default system precision (normally 2). There may be instances where it is desirable to change the default setting. In Version 5.1, we added the PRECISION directive so that an object definition can include a pre-defined precision. This provides the object more independence from the application from which it is being called better encapsulation. STATIC Directive In some instances, an object may need to add certain variables to the list of data elements that are kept within the object basically, to extend the local property list. It would be useful for an object that is accessing a data file with an embedded IOLIST to be able to handle extensions to the IOLIST going forward. The object could execute code using the STATIC directive as follows: OPEN (n, IOL = * ) "DataFile" STATIC IOL=IOL(n) The STATIC directive declares that all the variables in the IOLIST are to be added to the list of variables to be maintained within the object in effect, adding the variables to the LOCAL variable list at run time. This allows the object to then read a record from the file and have the data elements remain available for subsequent calls to the object's methods. 30

31 What's New in 5.1? The OPEN OBJECT Clause Opens a file for exclusive use by an object. Logically attaches file to current object. Occurs only while executing in object. Denies any external alteration to file state. Allows limited inquiry functions (PTH, FIB, etc) other access is returned "invalid file access mode". Closes file automatically when object is dropped. Improves encapsulation. Assures external programs cannot influence object. In many instances, it is beneficial to have a file opened and used within an object. The problem is that external applications could influence the position and state of the file during the process. To avoid this issue, Version 5.1 introduces the OPEN OBJECT directive to indicate that a file being opened is for the exclusive use of the object. Only the object itself can alter the state of the file, and once the object is deleted, the file is automatically closed. Example: DEF CLASS "Customer" PROPERTY CUST_NO$, NAME$,ADDR$,CITY$,SALESMAN$,AMT_OWING LOCAL FILE_NO! FUNCTION FIND(X$) ENTER C$ READ (FILE_NO,KEY=C$)! Loads all the variables RETURN 1! FUNCTION NEXT() READ (FILE_NO,END=*NEXT); RETURN 1 RETURN 0! FUNCTION UPDATE() WRITE (FILE_NO); RETURN 1 END DEF! ON_CREATE: FILE_NO = HFN; OPEN OBJECT (FILE_NO,IOL=*)"ARCUST" RETURN In the above example, the file is opened in the ON_CREATE. There is no need to worry about closing the file since ProvideX does it automatically. Programs external to the object cannot alter the state of the file; however, system variables like HFN and CHN will reflect that the file is open, and some functions (PTH, FIN, FIB, etc.) can be used to query file attributes. 31

32 What's New in 5.1? Improved Method Declaration Simplified FUNCTION Clause Better support of in-line functions. No function End required ends at next function. New FUNCTION Clauses FUNCTION PERFORM xxx(...) Behaves like a PERFORM. Provides access to caller's data. Violates the rules of encapsulation. FUNCTION LOCAL xxx(...) Declares function to be called from within object. Direct FUNCTION Invocation Simplified FUNCTION Clause Version 5.1 also includes a number of enhancements regarding method declarations. Most notable is the ability to allow the direct in-line definition of functions this avoids having to place statement labels after the method declaration. Prior to Version 5.1, the declaration looked something like this: FUNCTION Delete(x$) Do_Delete FUNCTION Update( ) Do_Update END DEF Do_Delete: ENTER K$ REMOVE ( This makes it difficult to directly tie the code to the function name since you have to look up the statement label. As of Version 5.1, you are able to code the declaration as follows: FUNCTION Delete(x$) ENTER K$ REMOVE ( RETURN 1 FUNCTION Update( ) END DEF The function logic can directly follow the function/method declaration. Continued 32

33 Improved Method Declaration (Continued) New FUNCTION Clauses Two FUNCTION clauses have also been added. FUNCTION PERFORM indicates that the function logic is to be loaded and executed (as in a PERFORM); therefore, all variables will be shared with the calling program. Note: This violates the rules of encapsulation; however, it does have some uses. FUNCTION LOCAL indicates that the function is only to be called internally from within the object. It cannot be called externally. Direct FUNCTION Invocation Also new with Version 5.10, is the ability to directly invoke functions. In prior releases, a function had to be invoked within an expression and return a value. It is now possible to directly invoke such methods. Example: MyObj'Delete("000123") 33

34 What's New in 5.1? Improved Performance Faster Property Lookup Improved compiled code lookup speed. Cached table of object names. Reduces lookup time for properties. Auto-Program Cache Programs that define classes are forced into cache for duration of object existence. Improves performance. Internal caching of function addresses. Improves function lookup and transfer times. and the ProvideX OLE Server more on that later One of the major performance problems caused by object-oriented programming is due to the time it takes to look up all the property names and functions associated with an object. When a standard program is saved, all variable names and labels are resolved, and direct references to them are allowed at run time. Objects however, are independent. Prior to Version 5.1, ProvideX had to look up both object function entry points and property names on every usage. To save lookup time, Version 5.1 includes two caching techniques that, wherever possible, preserve the locations of properties and functions within objects. This improves general overall performance when using ProvideX OOP. To reduce load time, all active object definition programs are automatically loaded and locked into program cache when methods are invoked. 34

35 Putting It all Together Let's take a look at how you would actually use this Note: This example is designed for illustration purposes and is not fully object oriented. It does not encapsulate the file to avoid outside influences. The following is an example of the definition and use of a Customer object. Customer Class File - Customer.PVC DEF CLASS "Customer" PROPERTY CUST_NO$ SET CHG_CUST PROPERTY NAME$,ADDR$,CITY$,SALESMAN$,AMT_OWING! FUNCTION FIND(X$) ENTER C$ READ (%CUSTOMER_FILE,KEY=C$)! Loads all the variables RETURN 1! FUNCTION NEXT() READ (%CUSTOMER_FILE,END=*NEXT); RETURN 1 RETURN 0! FUNCTION UPDATE() WRITE (%CUSTOMER_FILE); RETURN 1 END DEF! CHG_CUST: ENTER C$ READ DATA FROM "" TO IOL=IOL(%CUSTOMER_FILE) LET CUST_NO$=C$ READ (%CUSTOMER_FILE,KEY=C$,DOM=*END); RETURN! ON_CREATE: IF %CUSTOMER_FILE=0 THEN OPEN (GFN,IOL=*)"ARCUST"; LET %CUSTOMER_FILE=LFO %CUSTOMER_OBJECT++; RETURN! ON_DELETE: IF --%CUSTOMER_OBJECT<>0 THEN RETURN CLOSE (%CUSTOMER_FILE); LET %CUSTOMER_FILE=0 RETURN Continued 35

36 Putting it all Together (Continued) Now, to actually use the Customer class 0010 C=NEW("Customer") 0020 INPUT EDIT "Customer #",X$:"000000" 0030 sts = C'Find(x$,ERR=Bad_cust) 0040 INPUT EDIT "Name:", C'Name$ 0050 sts = C'Update() 0060 sts = REF(DROP C) In actual fact, a real life example would most likely use objects to control access to your data files/database as follows: Customer Class File - Customer.PVC 0010 DEF CLASS "Customer" 0020 PROPERTIES CUST_NO$,NAME$,ADDR1$,ADDR2$,CITY$,AMT_OWING,LAST_ORD_DT$ 0030 FUNCTION Find(X$) Get_Customer 0040 FUNCTION Update() Upd_Customer 0050 LOCAL File OBJECT 0050 END DEF 0100 ON_CREATE: ENTER Db 0110 File = Db'Open("ARCUST") 0120 RETURN 0200 Get_Customer: ENTER C$ 0210 READ (File'Channel,KEY=C$)! Loads all the variables 0220 RETURN Upd_Customer: 0310 WRITE (File'Channel) 0320 RETURN 1 The Db'Open function verifies that the file is open and, if it is not, creates a new object to handle the file access that opens the file. If it is already open, then the Db'Open function simply increments the reference count. Either way, the Open function returns the object identifier of the file. Since the Customer class definition indicates that the LOCAL File property is itself an object, when we attempt to destroy a Customer object we reduce the reference count to the File object. If no other reference to the File object exists, it is destroyed, resulting in the closure of the file. Your application would be: 0010 DB = NEW("Database"), C=NEW("Customer", DB) 0020 INPUT EDIT "Customer #",X$:"000000" 0030 sts = C'Find(x$,ERR=Bad_cust) 0040 INPUT EDIT "Name:", C'Name$ 0050 sts = C'Update() 0060 sts = REF(DROP C) 36

37 How do Objects Work? okay, not really So, what's going on behind the scenes? Object PropVal1 PropVal2 PropVal.. Object PropVal1 PropVal2 PropVal.. Class Func1 Func2 Func.. PropDef1 PropDef2 PropDef.. Like1 Like.. Object PropVal1 PropVal2 PropVal.. Class Func1 Func2 Func.. PropDef1 PropDef2 PropDef.. Like1 Like.. Class Func1 Func2 Func.. PropDef1 PropDef2 PropDef.. Like1 Like.. When designing an application it is a good idea to understand exactly what is going on behind the scenes. If you understand what the system (in this case ProvideX) is doing to implement and control objects, then your design, development, and debugging process will be a lot simpler. Every object in the system contains a list of current property values and an associated class definition. The class definition is what defines the methods an object has, not the object itself. The class definition also contains a list of property definitions for the object. In order to support inheritance, each class definition may contain a list of LIKE references that point to other class definitions. Those class definitions themselves may contain additional properties, methods, and other LIKE references. When an application references an object property (or the object itself references a variable), the list of current property values is searched for a match. If no match is found, the class structure is searched to see if a property definition exists for that name; if it does exists, a new value entry is created for the object. When an object method is invoked, the class structure is searched in order to locate the method. Note: When class structures are searched, the primary class definition is searched first followed, in order, by each of the LIKE definitions. The first match will be used. 37

38 When to Use OOP (or not) OOP involves overhead. Referencing properties is slower than referencing variables. Avoid replacing all variables with object properties. Invoking methods is as fast as issuing a CALL. However, remember CALL is slower than GOSUB. Replacing all IO with objects is likely a bad idea. Yes, you gain control, but you add overhead. If performance is an issue in-line read/writes are better. OOP hides a lot of logic. This is great for writing modular code. This makes it a pain to follow "what did what ". Inheriting logic often means asking: How the heck did I get here? Overhead In general, object-oriented programming provides a great deal of assistance in terms of system design and development; however, like all good things, it should be applied in moderation. Object-oriented programming (referencing object properties and functions) is a lot more time-consuming than directly accessing variables and GOSUBs. When designing applications, you need to strike a balance between OOP and more straightforward coding. For example, it is possible to provide a File I/O object that centralizes file access. However, you must consider the overhead of logically replacing all READ/WRITE directives with CALLs, which is effectively what methods are. If you maintain the data elements as properties within the object, you will add significant overhead on each and every reference to a variable. It is better to develop a business or application object that executes distinct application-related functionality. Hidden Logic Objects are great for modular coding. However, when things go wrong, as they sometimes do, figuring out what happened and how it happened can be a major headache. Inheritance is a wonderful concept, but it can result in surprising results. Use the ProvideX trace functionality to help resolve these issues. A Statistics INFO button has been added to the Windows version of ProvideX to help break down some of the complexities of using objects. Using INFO, you will be able to see all active objects as well as any of the objects they inherit. 38

39 When to Use OOP (or not) of it becomes habit forming. Yes, Object Oriented Programming can become addictive. Often, what starts out as just one object becomes many many objects. They have a nasty habit of multiplying. 39

40 ProvideX OLE Server Providex.Script ProvideX becomes COM object. New ProvideX.Script object is accessible from virtually any language. Provides the following methods: Init (path) Execute (statement) Evaluate (expression) Run (program) Reset ( ) NewObject (name, params ) The ProvideX.Script OLE server allows external applications to directly invoke and interact with ProvideX and ProvideX objects. The server can be used by virtually any COMcompliant application or programming language such as VB, Delphi, VB script, VBA. Methods The OLE server itself has 6 methods: Init (path) Execute (statement) Called before accessing any other method in the script engine in order to set the working directory for the server and perform binding to the ProvideX dll layer. The path should be set to the desired working directory, or blank to indicate the current directory. (In most cases, the current directory will be the system directory) Invoked to execute any ProvideX command. Evaluate (expression) Evaluates and returns the expression provided and returns its value as a variant. (It can be used as either a numeric or string.) Run (program) Reset ( ) Runs the specified program. This method does not return until the program ends. Closes all LOCAL files and clears variables. (It executes a BEGIN) NewObject (name, params ) Creates a new object of the specified name and returns an object reference. Continued 40

41 ProvideX OLE Server (Continued) Associated Properties There are also three properties associated with the script interface: Instance State Parameter Returns a unique string to identify the server during its lifetime. Returns the state of the server. 0 (zero) is returned for un-initialized, and 1 (one) is returned for initialized. Read/write property used to access the specified ProvideX parameter. Additional Properties To create an object within the OLE Server, the method NewObject is used. It returns an object identifier to the ProvideX object that was created. Along with the ProvideX defined properties and methods, the OLE server adds the following properties: Instance ScriptObject Returns a unique identifier of the ProvideX.Script object that was used to create the automation object. The importance of this is due to the fact that the automation object cannot be passed to another ProvideX.Script server. Returns the parent ProvideX.Script object. CmdHandle Returns the ProvideX handle that the automation object is tied to. 41

42 ProvideX OLE Server Naming Conventions COM does not support $ or % suffix. A single character prefix is required: s for string variables n for numeric variables i for integer variables o for object variables (required). Examples: Cat$ becomes scat Dog becomes ndog Pig% becomes ipig One thing you should be aware of is that COM is generally data-type insensitive. You can access a numeric value as either a string or a number. This causes a problem when dealing with the ProvideX OLE server, since in ProvideX you can have Cust_no$ and Cust_no as two unique data variables. To avoid this problem, the OLE server mandates that all property references indicate the property type in the first character of the property name. This means that all references to string properties must have an 's' followed by the property name; all numeric properties must have an 'n' followed by the property name; and, all integer properties must have an 'i' followed by the property name. If a property is itself a object identifier, the property name should have an 'o'prefix. The suffixes are only for use by programs using the OLE Server - not by the ProvideX application itself. This means that the property Cust_no$ in ProvideX would be scust_no when referenced by the OLE Server and the property Cust_no in ProvideX would be ncust_no. DO NOT use the SUFFIX in the PROPERTY DEFINITION! Use of the 'o' prefix allows the specification of properties and/or methods within ProvideX objects to be declared themselves as objects. 42

43 ProvideX OLE Server ProvideX as Script Language ProvideX becomes a standard script language. In Web Pages In ASP In MS Office script interface. The.pvs extension identifies ProvideX script. Through the use of the OLE server, ProvideX itself can become a script language for any Windows system. Any file with a.pvs suffix will be passed to the script engine to execute as a script. Web pages and IIS ASP servers can use the ProvideX script engine as well. Script definitions vary slightly from regular ProvideX in that the text is basically passed to ProvideX as a series of execute commands. However, there is an exception: any code that starts with a statement label and ends with END will be considered a program and built as if it was typed in. After the END directive, you can then issue a GOTO label; RUN to begin execution of the code (The short cut is #xxxxx where xxxx is the label). Script-based programs do not support line numbers. When an error occurs in a scriptbased program, the line number reported will reflect the line number from the original script input file/document. 43

44 Sample Objects *OBJ Library General use objects are stored in here. Do not alter these objects this may cause future upgrade problems. The following are Version 5.1 objects: *OBJ/WINAPI *OBJ/WindX Data Dictionary Objects New objects to reference Data Dictionary Allow for file creation, modification, and reference 44