OOP for the AS/400 developer: introduction to OOP

What is OOP and why is it important?

It’s “object-oriented programming” and it’s a different way of thinking about developing, supporting, and extending applications.  C#, Visual Basic, and Java are three of the best-known OO languages.

There are a number of new concepts in OOP, including inheritance, abstraction, encapsulation, and polymorphism.  At risk of upsetting the purists, these concepts aren’t required for every OO program.  They offer an extremely powerful way to share, override, and extend previously-written code, so a well-designed OO application becomes relatively easy to enhance and extend.  On the other hand, a poorly-written OO application can turn into a nightmare, not just from the code itself, but from poor use of the concepts mentioned above.  OOP enables both “spaghetti code” and “spaghetti apps.”

In the AS/400, we use “procedural programming” methodology, where we ”do things” to data.  Most AS/400 developers use ILE RPG to specify a series of steps to perform a task, which could be anything from updating a customer’s receivables balance to changing the status of an order.  Each step usually consists of an operations code (think “verb”: ADD, EVAL, CHAIN) and one or more data elements. 

Object-oriented programming is about objects (think “nouns”).  Using the OOP term “class” to define an object, what sets OOP apart from procedural programming is that a class defines a “thing” (a customer or an order) in two categories: the data itself and what can be done to that data.  The OOP focus is on the thing, not on the action.  

For the sake of this discussion, ignore the “database” concept–the point of the database is to persist (save) the data over time, so when we talk about the class “Customer”, we’ll assume the data for the specific customer has been made available.  So, our Customer class will contain its data members (data fields) and methods (update outstanding balance, delete, change status).  So, to update a customer’s balance, the code might look something like this:

Customer.UpdateBalance(OrderAmount);

 This code says, “Pass the ‘OrderAmount’ into the ‘UpdateBalance’ method in the ‘Customer’ class and execute the method.”

When developing an OO application, the first steps include defining objects (customer and orders) and defining what actions will be taken on each object.  So, it’s fair to say that more front-end design work is helpful (but not necessary) in an OO application. 

One way to understand the “Customer” class is considering it as a combination of the database record(s) and at every program that modifies the customer database.  In reality (a useful concept even in the OOP world),  there would be more than one class defining a customer.  Name/address, contact information, and history are a couple of possible classes each defining a specific concept of the customer.   

 Because classes are self-contained, it becomes very easy to enhance an application by adding a class with a new capability and then referencing that class.

How does this translate into the AS/400 environment?  Well, it doesn’t, really, but one weak analogy for a class is a service program with local variables and multiple procedures that modify those variables.  In OOP, though, a programmer has the ability to execute a method defined within the class without the execution thread being within the class.  A class is a container for the data elements and all the actions (methods) that are valid for those data elements, and all of those “members” (the term for the elements that comprise the class) may be externally accessible. 

An aspect of OOP overlooked by procedural programmers is its ability to support rigorous automated testing.  When the code that updates the customer file is spread over dozens (or hundreds) of programs, testing is nearly impossible.  But when the code is centralized in a couple of classes, it’ easy to write test scripts that test every method in a class, without requiring database or manual user interface (UI) activity (a “best practice” for AS/400 developers is to write a test program for every service program).  Whenever a class (or service program) is changed, part of the quality assurance process is to execute the test program and to confirm the results are as expected.