Achieving some kind of polymorphism in C/AL has always been a problem. The fact that true polymorphism with pure C/AL is outright impossible has not stopped the more stubborn of us to at least give it a try. That’s how some cool patterns emerged.
The façade pattern has been evangelized by Gary Winter so eagerly that he couldn’t find time to formally describe it. The other pattern that comes close is the variant façade pattern. It was formally described at the patterns Wiki page, but – to the best of my knowledge – was first figured out by Arend-Jan Kauffmann.
These two patterns can go a long way. No, they are not coming anywhere near true polymorphism, but will achieve some cool loose binding when you need it.
In my practice, I took a step further, and I think it’s about time I share it. Let’s see if it works for you as well as it did for me.
In my last post, I babbled at length about what loose coupling is, how both the façade and the variant façade patterns are trying to achieve it. So before you continue, if you haven’t read that post, now is a good time to do it.
Okay, now that we are on the same page, let me reintroduce the problem I put in front of you last time: shortcomings of the argument table .
First, it can only handle simple types, and if you need to pass more context that can’t reasonably be represented by a single record without paying a hefty price somewhere down the road. And then, if you want to combine it with more arguments, you loose the versatility of the CODEUNIT.RUN construct.
So, I figured out – why not use TempBlob as the argument table? It has only one useful field, called Blob (duh!) and is only intended to be used as a temporary record instance. How does that help? Well, in a ton of ways.
To start with, a Blob can hold as much information as you need. Any piece of information that runtime can handle, no matter of its type, structure, or complexity, can be represented as an array of bytes, and that’s what a blob in fact is: a binary large object, just as it says on the tin.
The only problem is, how to get anything into a blob. The answer is – serialization. That’s a term that .NET developers are far more familiar than C/AL developers, but in case you haven’t heard it yet, it’s the process of storing (serializing) an instance of an object together with its state into a format that allows storing that state outside the memory, typically for the purpose of restoring (deserializing) the object with its state later, possibly even on a different machine.
While in .NET serialization is typically only an attribute away, in C/AL we need to handle it manually. But we can handle it. We can serialize records into XML by using XMLports. Or, we can write our own serialization routines in case XMLports cannot help.
In any case – the point is – you can serialize just about anything.
And once you serialize anything, you can put it into a Blob.
Enter the TempBlob pattern:
Now, this looks a lot like the façade pattern, and in fact it is. Except that it allows you to pass far more context into the dependencies that façade, with or without variant, allows you to. Remember, a function can only have 20 parameters in C/AL, and a TempBlob can hold up to 2GB of data structured any way you want.
An example of how to pass a dictionary from one codeunit to a façade (and ultimately to the dependency) is this:
This TempBlob Management codeunit is very simple, and its purpose is to handle serialization and deserialization of stuff into TempBlob by using JSON as the serialization format (it can be anything else, but JSON is good enough).