When we discover redundancies while writing code, the DRY principle (Don't Repeat Yourself) encourages us to refactor
our code into reusable definitions. Reasons cited for writing DRY code include:
- Code that is easier to maintain,
- Code that scales better as system load increases, and
- Reduced redundancies in process logic.
With PeopleCode, we have two reusable options:
- Function Libraries
- Application Classes
We asked our LinkedIn audience which option they would choose.
The poll results show that 76% would choose Application Classes! Wow! 76% will
defer to Object-oriented programming. This is one of those questions that has no right or wrong answer. Both are
effective. But is there a more correct answer? Is there a time when using one over the other is more appropriate?
Let's consider App Classes first. Every App Class involves object creation overhead, which
means using objects has a cost. But there are two features App Classes contain that set them apart from Function
Libraries:
- State: App Classes have an internal state. App Classes have private, internal variables that persist
beyond method invocation.
- Dynamic Execution: At runtime, we can create objects, set properties, and invoke methods that didn't
exist during design time. Function libraries can't do this.
If I know that my solution will require internal state or dynamic execution, I choose App Classes; function libraries are not an option.
Here are a few other reasons people choose Application Classes over Function Libraries:
- To leverage dynamic testing frameworks such as PSUnit.
- Extensible framework development through inheritance and composition.
Is there a place for function libraries in modern PeopleCode? This is an interesting
question that I think Oracle answers for us. If you look through Oracle's Fluid-specific PeopleCode, you will see a
lot of references to Fluid-specific Function Libraries. Why? If you don't need internal state or dynamic execution,
then a Function Library may be the fastest, lightweight option.
Consider the following example (adapted from Base64 Encoding with Emoji):
/****
* You may find a subset of supported character sets in the Javadoc:
* https://docs.oracle.com/javase/8/docs/api/java/nio/charset/Charset.html
*/
Function base64_encode(&textToEncode as string, &charSet as string) returns string
Local JavaObject &encoder = GetJavaClass("java.util.Base64").getEncoder();
Local JavaObject &bytes = CreateJavaObject("java.lang.String", &textToEncode).getBytes(&charSet);
return &encoder.encodeToString(&bytes);
End-Function;
Does it make more sense to expose this reusable algorithm as a Function Library or
Application Class method? What do you think? If you choose App Classes, why? If you prefer Function Libraries, we
would love to hear your reasons!
At JSMpros, we teach PeopleTools and PeopleCode tips like this in every class. Check out our online schedule to see what we're offering next. Would you prefer to learn at your own pace? Purchase a subscription to access all of our on-demand content at discounted rates!
.jpg)
