Last active
April 22, 2017 23:21
-
-
Save abiodun0/dc60df0132a67e27cf0fe6b48a20ff74 to your computer and use it in GitHub Desktop.
DI functional
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
exports.myService = { | |
f: function (x, y) { someServiceImpl.doThing(x, y); } | |
}; | |
// functional DI | |
exports.myservice = function(someServicImpl) { | |
return { | |
f: function (x, y) { someServiceImpl.doThing(x, y); | |
} | |
} | |
// I have actually be researching this question actively for the past month or so, | |
// and basically come to the following conclusion. | |
// If you look at OO dependency injection principles and you carry them the extreme, | |
// you get one method per object, and one constructor. This leads to functions that take their | |
// dependencies immediately like f(service1, service2, value1, value2). | |
// You can use currying to decouple the temporal aspect of the application of these services1, | |
// and wire them manually later on at the mount point. | |
// Currying also trivially takes care of the injection of factory functions | |
// like f(switch, value1, value2). | |
// Carrying the idea further to only using functions and not mixing OO and FP, you get signatures like | |
// f(behavior1, behavior2, value1). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment