{"id":426,"date":"2016-02-16T04:43:21","date_gmt":"2016-02-16T04:43:21","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=426"},"modified":"2016-02-23T18:27:41","modified_gmt":"2016-02-23T18:27:41","slug":"inversion-of-control","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2016\/02\/16\/inversion-of-control\/","title":{"rendered":"Invert Your Inner Control Freak!"},"content":{"rendered":"\r\n

Arvind's recent<\/a> posts<\/a> have had me thinking. While the spellchecker he outlines is really just for illustrative purposes, its actually an example that is great to show the power, ease of use, and connectivity of MATLAB. I'd like to add to that the ability to showcase a software design pattern or two. Today I'd like to continue Arvind's spellchecker example to meander a bit around the topic of inversion of control.<\/p>

Inversion of control is sometimes called the Hollywood principle:<\/p>

\"Don't call us, we'll call you!\"<\/i><\/p>

It is a technique for structuring software that encourages creating abstractions and avoiding direct dependencies on the components and services that actually make the software work. When first encountered it can be a bit counterintuitive, but it facilitates flexibility and modularity like nobody's business! The big takeaway is that components should really avoid doing work themselves and instead rely upon the abstractions that collaborators can fulfill. Got it? Not really? Lemme show by example. Take a look at the start of the spellcheck constructor from last post:<\/p>

\r\nfunction<\/span> obj = spellcheck(varargin)\r\n    \r\n    % Make Jazzy available to MATLAB<\/span>\r\n    import com.mathworks.spellcheck.*<\/span>;\r\n    \r\n    % Setup a default language.<\/span>\r\n    obj.Dictionary = which('en_USx.dic'<\/span>); % default<\/span>\r\n    \r\n    % Create a jazzy spellchecker<\/span>\r\n    obj.Handle = SpellCheck();\r\n    obj.Handle.setDictionary(obj.Dictionary);\r\n    obj.Handle.verbose = true;\r\n    \r\nend<\/span>\r\n\r\n<\/pre>
\"Well of course!\" you might say, \"How else would we get anything done?\" you might ask. After all, we need to invoke this code somehow somewhere, why not in the constructor? Well, let's remove one of these hard dependencies to see how its done. Today I'll show this for the dictionary file, although the same process would still apply to the spell checking engine just as well.<\/p>
The approach needed is to create an abstraction, and rather than hardcoding which<\/i> dictionary in the constructor, we should pass in the abstraction. We ask the creator of our instance to provide what we depend on rather than ourselves creating a concrete version of what we depend on directly in the constructor. The nice benefit here is that when we ask for this to be provided in the constructor inputs, many more possibilities open up in the future for which things can be passed in. As the world evolves around us we see that this leads to much more flexibility and ability to react to change and reuse our software in contexts not envisioned when it was created.<\/p>
For our spellchecker, let's remove our explicit reference of the dictionary. The first step is to create an abstraction:<\/p>
\r\nclassdef<\/span> Dictionary < matlab.mixin.Heterogeneous\r\n    \r\n    properties<\/span>(Abstract)\r\n        DictionaryFile\r\n    end<\/span>\r\n    \r\nend<\/span>\r\n\r\n<\/pre>
Now that we have the abstraction we can just operate on that abstraction by asking that it be passed into the constructor:<\/p>
\r\nfunction<\/span> checker = spellcheck(dictionary)\r\n\r\n    % Hold onto our dictionary<\/span>\r\n    checker.Dictionary = dictionary;\r\n\r\n    % Create the jazzy spellchecker<\/span>\r\n    checker.Handle = com.mathworks.spellcheck.SpellCheck();\r\n    checker.Handle.setDictionary(dictionary.DictionaryFile);\r\n    checker.Handle.verbose = true;\r\n\r\nend<\/span>\r\n\r\n<\/pre>
It's totally subtle!...but I love seeing this. In my mind the ideal constructor is doing nothing but setting properties from the values passed in. If we did this exercise once more for the Handle property we would also pass in the SpellCheckEngine<\/tt><\/b> or some such and all the constructor would do would set these two properties.<\/p>
For reference here is a complete simple version of this spellchecker. (note depends on the small java code developed a couple posts ago<\/a>).<\/p>
\r\nclassdef<\/span> spellcheck\r\n    \r\n    properties<\/span>\r\n        Dictionary;\r\n    end<\/span>\r\n    \r\n    properties<\/span>(GetAccess=private, SetAccess=immutable)\r\n        Handle;\r\n    end<\/span>\r\n    \r\n    methods<\/span>\r\n        function<\/span> checker = spellcheck(dictionary)\r\n            \r\n            % Hold onto our dictionary<\/span>\r\n            checker.Dictionary = dictionary;\r\n            \r\n            % Create the jazzy spellchecker<\/span>\r\n            checker.Handle = com.mathworks.spellcheck.SpellCheck();\r\n            checker.Handle.setDictionary(dictionary.DictionaryFile);\r\n            checker.Handle.verbose = true;\r\n            \r\n        end<\/span>\r\n        \r\n        %% CHECK Method to check an input string<\/span>\r\n        function<\/span> check(checker, inputStr)\r\n            checker.Handle.checkSpelling(inputStr);\r\n        end<\/span>\r\n    end<\/span>\r\n    \r\n    \r\nend<\/span> \r\n\r\n<\/pre>
Anyway, now that we are operating on this abstraction we can start creating some dictionaries to fulfill it:<\/p>
\r\nclassdef<\/span> AmericanEnglishDictionary < Dictionary\r\n    \r\n    properties<\/span>\r\n        DictionaryFile = 'en_USx.dic'<\/span>;\r\n    end<\/span>\r\n    \r\nend<\/span>\r\n    \r\n\r\n<\/pre>
checker = spellcheck(AmericanEnglishDictionary);\r\nchecker.check('Do you speak MALTAB?'<\/span>);\r\n<\/pre>
Input : MALTAB\r\n\tSuggestion: MATLAB\r\n<\/pre>
Oops! Indeed:<\/p>
checker.check('Do you speak MATLAB?'<\/span>);\r\n<\/pre>
Silence is golden.<\/p>
\"\" <\/p>
But this doesn't work:<\/p>
checker.check('\u00bfHablas MATLAB?'<\/span>);\r\n<\/pre>
Input : Hablas\r\n\tSuggestion: tablas\r\n<\/pre>
...and nor should it, because we are speaking a different language. No problem, let's do the same thing for Spanish and we are good to go:<\/p>
\r\nclassdef<\/span> MexicanSpanishDictionary < Dictionary\r\n    \r\n    properties<\/span>\r\n        DictionaryFile = 'es_MXx.dic'<\/span>;\r\n    end<\/span>\r\n    \r\nend<\/span>\r\n    \r\n\r\n<\/pre>
checker = spellcheck(MexicanSpanishDictionary);\r\nchecker.check('\u00bfHablas MATLAB?'<\/span>);\r\n<\/pre>
El silencio es oro.<\/p>
\"\" <\/p>
Well, now that we are running at full throttle we can take this abstraction however far we want. We no longer have to be tied to an individual language file, the implementing dictionary can do whatever it wants as long as it stays true to the Dictionary<\/tt><\/b> interface. For example, let's see if we can use this to take care of an entire continent, namely North America. First, we'll need a couple more dictionaries for the Canadians, one more English:<\/p>
\r\nclassdef<\/span> CanadianEnglishDictionary < Dictionary\r\n    \r\n    properties<\/span>\r\n        DictionaryFile = 'en_CAx.dic'<\/span>;\r\n    end<\/span>\r\n    \r\nend<\/span>\r\n    \r\n\r\n<\/pre>
and a French dictionary. My apologies French Canadians! I know this is not correct, but it seems the Jazzy libraries with which we are demonstrating this concept don't have a fr_CAx.dic file. Sorry, but humor me this will get us through the example.<\/p>
\r\nclassdef<\/span> CanadianFrenchDictionary < Dictionary\r\n    \r\n    properties<\/span>\r\n        DictionaryFile = 'fr_FRx.dic'<\/span>;\r\n    end<\/span>\r\n    \r\nend<\/span>\r\n    \r\n\r\n<\/pre>
Up to this point we could only operate on a single dictionary. However, now that we are operating on an outside abstraction our code still works with totally different implementations of this abstraction. For example, nothing now stops us from implementing this reusable multi-lingual dictionary that builds off of all the dictionaries we already have:<\/p>
\r\nclassdef<\/span> MultiLingualDictionary < Dictionary\r\n    \r\n    properties<\/span>\r\n        DictionaryFile;\r\n    end<\/span>\r\n    \r\n    methods<\/span>\r\n        function<\/span> dict = MultiLingualDictionary(file, dictionaries)\r\n            dict.DictionaryFile = file;\r\n            \r\n            % Open our dictionary file and append all dictionary languages to it. Need<\/span>\r\n            % to open using UTF-8 encoding, which is the format for Jazzy dictionaries.<\/span>\r\n            [fileID, msg] = fopen(file,'w'<\/span>,'native'<\/span>,'UTF-8'<\/span>);\r\n            assert(fileID > 0, msg);\r\n            cleaner = onCleanup(@() fclose(fileID));\r\n            for<\/span> idx = 1:numel(dictionaries)\r\n                fprintf(fileID, fileread(dictionaries(idx).DictionaryFile));\r\n            end<\/span>\r\n        end<\/span>\r\n    end<\/span>\r\n    \r\n    \r\nend<\/span>\r\n    \r\n\r\n<\/pre>
and right off the bat I am going to use this to conquer the mighty North American spell checking problem!<\/p>
northAmericanDictionaries = [MexicanSpanishDictionary AmericanEnglishDictionary CanadianEnglishDictionary CanadianFrenchDictionary]\r\n<\/pre>
\r\nnorthAmericanDictionaries = \r\n\r\n  1x4 heterogeneous Dictionary (MexicanSpanishDictionary, AmericanEnglishDictionary, CanadianEnglishDictionary, ...) array with no properties.\r\n\r\n<\/pre>
Let's now pass that array of dictionaries into our new MultiLingualDictionary<\/tt><\/b> and we are good to go.<\/p>
checker =spellcheck(MultiLingualDictionary('northAmerican.dic'<\/span>, northAmericanDictionaries));\r\n\r\nchecker.check('\u00bfHablas MATLAB?'<\/span>);\r\nchecker.check('Do you speak MATLAB?'<\/span>);\r\nchecker.check('Parlez-vous MATLAB?'<\/span>);\r\nchecker.check('Do you speak MATLAB, eh?'<\/span>);\r\n<\/pre>
I kinda wanted<\/i> that last one to yell at me. That's two strikes against me from my Canadian friends today.<\/p>
So there we go, a much more flexible system we have now, at least as the dictionary management goes. I leave for you the exercise to do the same thing for the spellchecking engine.<\/p>
What do you think? Are you convinced? Are you an inversion of control expert already? Tell me how you apply the technique in MATLAB.<\/p>
\"\" <\/p>
Note, I've marked it Heterogeneous<\/a> because I am going to want to take advantage of MATLAB's fundamental array nature, but I'd like to do so with different dictionary implementations.<\/p>
This looks innocuous enough but it does not practice the principle of the day. Here in this constructor snippet we are setting the Dictionary<\/tt><\/b> property explicitly as well as creating our spell checking engine (Jazzy). This is OK for small programs, but this approach leads us to rigidity in larger systems. The spellchecker now has a concrete dependency on both the Jazzy library and this particular dictionary. This means that we can't use this spellchecker technology in the absence of Jazzy (like with a different spellchecking engine, perhaps in -nojvm<\/tt><\/a> mode), or in the absence of the English dictionary.<\/p>