Classes

Introduction 

My first course of programming (C++) in college introduced me to the concept of classes and objects; I had to use OO programming in most of IT courses in the 3 years before I god my degree. Having been working in various environments (Web, Databases, C++ Programming) before jumping into Peoplesoft, I didn't practice OO Programming in my early years, or considered working with classes and objects as a constraint of the programming language. This was also my approach when I jumped into the Peoplesoft world, until...

When I started working as a Peoplesoft Developer, I started modifying pages here and there, then I jumped in SQR and Peoplecode, discovered the APIs, and eventually the functions. I remember that, for a reuse purpose, I created a generic function to generate a CSV file with as input the file name and path, the separator, the quotes, etc... I reused my function to generate other CSV files and it worked great. One day, I got to develop the opposite : a CSV file reader. I tried to follow the same logic, but the treatment of each CSV line changes from a case to another; I tried to find a way to call dynamically a function without having to hardcode the call in a switch-case, or using @, such as when we get a record from its name contained in a string variable. I didn't find anything until...

Until... I read about Application Packages. The solution was to create a CSVReader class with an abstract method ReadLine (called for each line read in ReadFile) which shall be implemented in each subclass - the real CSV Readers. Ok I might be to advanced for beginners.

Example

I think the best way to explain the concept of classes is to give an example with commonly used classes. Everyone should know the Record class, from the APIs; it is used at large in a lot of Peoplecode pieces. You don't know how the Record type is implemented, and you don't really want to. However, you can declare a variable of type Record, you can interact with it using some functions (GetField, Insert, SelectByKeyEffDt ), and you can visualize its properties (FieldCount, Name). You can create different variables of type Record, built differently (using CreateRecord(), GetRecord(), ...); you can build a record from scratch, insert manipulates rows, or you can populate it from the component processor.

The functions (methods) and properties that you can use to manipulate an object of type Record (available to you) are the public elements of the class.  Basically, everything you see in the APIs Peoplebook consist of the public properties and methods.

If there is a public part in a class, there should be a private part; of course, and there is even a protected part, but we can forget it for now.  The private part consists of all the properties and functions that you don't want the programmers to be able to manipulate.  Let's imagine that the way Oracle implemented the Record class.  A possible implementation (not the best) would be to have two variables, an array of string for the field names, and an array of array of any for the values (1 array per line).  What happens if a programmer decides to insert a variable in one of the arrays ?  The whole organization might become messed-up.  Another programmer might decide to add a field in the list of field names; same result.  One of the goal of having private elements is to avoid those problems; the core elements should only be modified following precise rules, rules that you implement in the public methods.  Of course, sometimes, it can be ok to let the user modify a variable directly; some purists will tell you that you need a getter and a setter (methods that returns the value or that sets the value), but this is not the most important at my eyes.

To be continued...

Resources

Application Packages - Oracle Peoplebooks
Object Oriented Programming - Wikipedia