I’m starting to sound like a broken record I’m sure – constantly going on about why we should be using interfaces in Salesforce more, why we should be breaking tightly couple code blah blah… Go here and here if you haven’t already been exposed to my rabbiting!
Now, I don’t just write this stuff I try and make sure I live by my own word as much as possible. But, as I’m sure you all of you that have tried to decouple things more in Salesforce, this decoupling can quickly become a mess: making sure the right concrete class is being called at the right time is only simple at first. It’s the same old story: at the time everything makes sense but going back to that code one, two, three months later and you sit there thinking: “what the hell was I on when I wrote this?”
It was such a moment earlier in the week that led me to face up to the challenge I set myself a while ago and do something about the way in which I managed interfaces and dependencies in my code. With the overall goal of building a framework to manage all of this in a clean and repeatable way. I may well find that this has been done before but it has been a wet Sunday and wanted to have a stab at it myself.
So – looking to other languages the obvious answer is to tend towards some kind of dependency injection, inversion of control or service locator – but which one and why? Well, they’ll all similar but different and frankly an in depth discussion about which to use and why is way beyond the scope of what I wanted this post to be. Suffice to say I believe I have gone for a form of interface dependency injection with some kind of inversion of control container – if all of that seems a bit vague then it’s because it is; I’m not really one for theory and names so please excuse any incorrectness there.
Also I’m not going to post all of the code here as I don’t think it’s appropriate but if you want to follow along as I go through/around the various components then the Force.com project can be found on Github.
The force.com platform provides a big challenge for dependency injection as there’s no form of reflection or inspection – it’s for this reason I have decided to adapt interface injection. Constructor based injection could have been an option but the novel method used to dynamically instantiate classes means that there’s no construtor that I can inject into. At the heart of this system is the interface IHasDependencies: any class that you want to have dependencies injected into it by the container needs to implement this interface. Using the interface means that this is the only thing the class developer needs to be aware of; this keeps the classes decoupled and unaware of the container that’s wiring them up.
As you can see the interface is very simple with only two methods. The first, getDependencies, returns a Map describing the dependencies that the class requires. A map is passed as it allows me to make use of the fact that non primitive objects are always passed by reference on the platform – this means that the container can populate the value portion of the map with the concrete classes and they get automatically “passed” back to the class that needs them. This little trick means we can again keep everything nicely decoupled.
The second method, gotDependencies, is a little bit of a hack but a necessary one. The container calls this once it has set all of the values in the map to concrete classes allowing the class wanting the dependencies to assign them out to members as it sees fit. This has to be done this way as without reflection/inspection the container cannot do it itself.
The other major part of this solution is the Container class. This class is responsible for maintaining a mapping of interfaces to concrete classes and then providing the appropriate concrete class when needed. The container calls itself recursively to get hold of all of the dependencies in all of the child classes as well. This recursion means that the consumer of the parent class need not worry about what other classes may or may not need to be configured in order to get a complete object graph. The container is able to seemingly dynamically instantiate classes but is in fact using the, probably now well documented and, extremely useful quirk of the JSON deserializer as described in much more detail here.
The rest of the functionality in the container class is to control the all important mapping. There are two available methods to setup the mapping: the first is a code based solution where you programatically add the interface to concrete mapping; this is useful in a test scenario where the mocks are likely to be one off test classes. The second method allows you to load the map up from a text file stored as a static resource. The file is currently structured as a simple JSON string representing a list of Container.ClassMapFileEntry objects. This approach gives you the ability to change functionality without deploying code – useful if you’re working in an environment where this can be an arduous process and also very handy for changing behaviour, such as integration points when moving code between environments as again no code needs to be changed between environments.
This post is short and lacking in any in-depth code walk through on purpose as I really just wanted it to be a marker, an introduction to what I hope will be an interesting discussion around the worthiness of this idea and how it can be improved (or a signpost to an existing fully fledged framework). There are plenty of features that I can think of – conditional mapping and instantiation control to mention just two – that could be added to this. Not to mention a whole bunch of error handling and test classes. But I feel that all of that is further down the road, the core of the solution needs to be well developed and debated first.
As I mentioned before, all of the code that I have so far can be found on Github and I encourage you to take a look, have a play and let me know of it’s many flaws. I include a couple of examples below that work with that code to exercise the basics of the container and interface – hopefully they will give you some idea of how it’s meant to be used. In the meantime I will work on a follow up post that goes through all of this in much more detail and breaks the code down section by section.
Looking forward to your thoughts.
I’ve had a stab at coming up with a way to manage dependent interfaces; a very simple IoC/DI solution for Force.com – I’m looking for ways to improve it and appreciate feedback. The code can be found over here.
I have added a bit more of a detailed walk though here