Reading other people’s code is great, be it good or bad, functioning or broken there is always something to discover – and generally it is something that makes you think: “d’oh, why didn’t I see that before?”
I liked my latest discovery so much that I thought I’d share it myself for those, like me, that just hadn’t thought of it or indeed seen it elsewhere.
Record Types are the subject. We are all aware of the complications that record types bring to Apex; often you will want to perform a different action in your code depending on the type of record that you have. Or you’ll want to get a value from one field for one record type but from another for the rest. That’s cool and it makes sense but how do you write the code to do that? Hard coding the record type id is a common practice and it just about works, so long as you have declared the record types in your production org as the ids stay the same when you create sandboxes. However things don’t normally happen this way. Often a developer will create a new record type in her sandbox and make use of it there but when you move between environments this code breaks as the record type doesn’t exist and if you create it the id will be different; try running CI in an environment like this! Another problem I see with this method is that, even if the ids are consistent betwwne environments the code is fairly meaningless: what exactly is id 00D123…..? So much for self documenting code, eh?
So, as you can probably guess this technique that I saw helps solve these problems. Actually what I saw was a step in the right direction… I’ve just taken it a little bit further.
In the code base that I was reading last week I saw a lot of declarations like this at the top of classes:
That solves a whole bunch of issues but why is it being repeated time and time again at the top of each class? Surely it would be better for all involved if these variables were declared and maintained in one place? The result of this thought is below: firstly a class called RecordTypeContainer that actually does all the hard work and then one called AccountRecordTypes which contains all of the record types for the Account object.
It would have been possible to wrap this all into the one class but splitting it out like this makes for easier to read code in my mind as I can say: AccountRecordTypes.Test1 in my code and it’s fairly obvious what I’m referring too. Obviously adopting this structure means we end up with lots of XXRecordTypes classes but it becomes a convention and not too much of a hardship. Whilst we have lots of RecordTypes classes we can be assured that they all work the same way because they all make use of the RecordTypeContainer class – this handles the intial getting of the record types, the storing of them and then the retrieval – again in a consistent and efficient manner.
The code itself is fairly simple and as such I’m not going to give a huge commentary on it; hopefully you can see how to apply it to other objects within your orgs but if not then just leave a comment.
Obviously it would be great if the platform had some form of static access to record types like this baked in and I’m sure over time it may well be added but in the meantime I’ve found this pattern to be really helpful and hopefully others will too.