Global class Manage Package Issue

Question

We have a Global class with Global Static method in our Manage package e.g:

(@Remote Action)
global static String doSomething(String quoteId, Boolean reconfig){}

Everytime, we have to add another parameter to this method, we have to deprecate this method and have to write a new one.

We want best Practice to design such classes/Methods in manage package to avoid deprecating methods each time we have to add another parameter in the method.

Answer 1

Methods marked as global can be called from outside your package. This means that anybody (ie: your customers, third party integrators...) who has installed that package can write code that references your global method. It has essentially become an external API.

If you suddenly change the signature of their method all their code will fail to compile and will break. That is not a good idea, as you're breaking backwards compatibility. That's why Salesforce doesn't allow you to change the signature.

Essentially, what you have is a versioning problem: how can I create a new version of my method without breaking backwards compatibility?

Some ideas off the top of my head as to what can you do around it:

• Create a new method with a different name to indicate that it's a different version (ie: doSomething_v2). Hopefully you can refactor all the different versions of the same method to use a common code path
• Serialize your arguments into a JSON string, and take that argument in your method (ie: doSomething (String jsonArgs). In subsequent versions, you can add more fields into the JSON payload without changing the method signature. This requires careful coding when deserializing the JSON, as you don't know what your users could be passing (some fields may be missing, etc).
• Your method could take a custom object in your package as an argument (ie: doSomething (Args__c args)). This sObject could contain custom fields for all the arguments that your method needs (and it could use validation!). In newer versions of your package, you can add extra custom fields to your custom object, if you need so.

We normally avoid using global methods if we can.

As a side note, this article by Martin Fowler about public vs published interfaces is worth a read: https://martinfowler.com/ieeeSoftware/published.pdf

global methods are essentially what Fowler calls a "published interface".

Answer 2

If it really needs to be global You could use a global class as a parameter instead of the various types.

Then, adding an option to the class will not require depreciation. Removing an option does though. Better than passing in signature.

You could also just use a string and pass a json string. Then deserialize to get the values. This is more CPU expensive and less obvious to those reading the code though

Or just don't use global methods if not needed