Wednesday, June 02, 2021

App Classes or Function Libraries: Which is Better?

As programmers, we look for patterns. And when we find them, we refactor them into reusable code. Keep it DRY: Don't Repeat Yourself. PeopleCode offers two reusable code containers:

  • Function Libraries
  • Application Classes

And this brings us to the great debate. Which is better? Object-oriented App Classes or procedure-based Function Libraries? I often ask my students this question. And if they prefer one over the other, why? Let's review the benefits of each:

Function Library:

  • Stateless
  • Simple
  • Must be declared

Application Class:

  • Stateful
  • Dynamic execution

There are other differences, but they are irrelevant for this comparison. For example, Application Classes have inheritance (some would say inheritance is NOT a benefit). The value of inheritance is reuse, but then a function can call a function, which is also reuse.

When asking students about their preference, here are a few of my favorite answers:

  • Choose App Classes because they are new.
  • Choose App Classes because they are object-oriented.
  • Choose App Classes because we are supposed to.
  • Choose App Classes because everyone is doing it.
  • Choose Function Libraries because they work!

One of the most valuable features of App Classes is dynamic PeopleCode. Unlike Function Libraries, App Classes do not have to be imported/declared before use. This is how every PeopleTools framework works. As a developer, we create an App Class and register it with the framework. At runtime, the framework reads the metadata and invokes the App Class. A framework such as AWE, for example, knows nothing about my custom App Class. But it invokes my code nevertheless through functions such as CreateObject, ObjectDoMethod, ObjectGetProperty, and ObjectSetProperty.

Which one do I choose? Here are my decision criteria:

  • If I need dynamic PeopleCode, meaning no declaration, then the only solution is an App Class. Another way to think about it is if I'm writing code that invokes another code block and I don't know that code block at design time, but will fetch the name from the database, then I have to use an App Class.
  • If I'm writing code to plug into another framework, such as Event Mapping or Integration Broker, I will use an App Class.
  • If I want testable code to test through PSUnit, I will create an App Class (because PSUnit is a framework that will invoke dynamic code).
  • If I need to maintain state between method invocations, I'll choose an App Class.
  • Otherwise, I choose a Function Library.

Which do you prefer and why? What are other benefits of one over the other? Leave a comment to let us know what you think!

At JSMpros, we recognize the value of Application Classes and offer a two-day course dedicated to teaching object-oriented best practices. In fact, our next session starts on August 9, 2021. Register now!


Unknown said...

The psunit blog page you link to seems to be broken. The link to the psunit project is invalid?

Doris said...

What about the hybrid model? I'm writing app classes for testability and declaring legacy functions in the same class, after end-class?

Ricky said...

Excellent write up! While it is true that Functions must be declared...App Classes when called by other pcode still required import declaration then instantiation etc. So yes from AWE or from Activity Guide Composer steps, it's nice to just enter the App Class and it executes.

When considering App Class vs Functions in the PeopleSoft world it's akin to teaching an old dog a new trick. Personally while App Class in the big picture provide more efficiency, it can become more complex when troubleshooting. An error in a function can be within that function, an error with an App Class can be somewhere else like 3 levels deep and by the time you find it, you've lost track of where you

Jim Marion said...

@Ricky, exactly! I'm not even sure App Classes are more efficient :).

About the import/declaration. It is true that at Design Time, we must import, but when using CreateObject, we can create instances of classes without importing. That is how the frameworks work, and frameworks are the only time you would do this. You wouldn't do that as a standard practice.

Jim Marion said...

@Doris, this is INCREDIBLY common. My favorite one is PT_PAGE_UTILS.SetDefaultViewport. It is a one-liner that invokes an existing function library.

What you are saying is exactly the point. I think we often see one or the other, but we should really see both working together in harmony. They are both great tools.

Jim Marion said...

Yes, the PSUnit project is no longer available from the Oracle blog. I believe that is an oversite. Fortunately, my friend Cache has a copy in his GitHub Repo: