Dependency Injection. It's an over complicated term for a really trivial pattern in development.
func addOp(a, b, op){
return op(a) + op(b);
}
Here op is a function being injected into another function. Nobody uses the term in functional/procedural programming because this pattern is obvious and ubiquitous in Higher order functions like map, reduce or filter.
When people use DI though it's used in the context of OOP, where a dependency is an object getting injected into another object through a constructor. People using this pattern tend to create programs that are littered with very abstract objects that can only work when injected with dependencies. Also the injected objects themselves may be DI dependent as well leading to crazy dependency chains (reminds me of inheritance ugh). All of this is done in the name of "modularity" and "unit testing." As you can imagine this pattern produces a sort of False composability where your code is littered with very abstract objects that are rarely ever reusable. If you want to compose object A and object B, you have to specifically design/code object A so that it can handle object B or vice versa. Because all object composition involves custom modifications to the code of an object it is a sort of broken implementation of modularity and reusability.
In a function, the only requirement for composability is matching types. All functions that return ints can be composed with one another without additional modifications. This is true composability and true modularity. The above example doesn't need dependency injection the same result can be achieved with this:
func add(a, b){
return a + b;
}
add(op(a),op(b));
So you can see why the OP listed DI as one of his complaints. He must be dealing with a highly Object Oriented code base that employs this pattern extensively.
> It's an over complicated term for a really trivial pattern in development.
Yes, but...
The objective of most business-oriented programs is to create the One True Function(tm), usually known to developers as a the "application." For everyone's sanity, this should be composed of smaller functions, which are sometimes called "objects." An object is just a function that was created using a specific creation template, usually called a "constructor."
For a pretty moderately sized application, the One True Function might be a tree of sub-functions which has hundreds or thousands of branches. Sometimes you might want to write the straightforward boilerplate code to attach items to this tree, but that could get tedious to maintain.
Other times, you might find a library that will automatically assemble your tree for you, as long as you specify up front in configuration that all of your fruits are apples and all of your leaves are green. This program is usually called a "DI framework."
Hopefully, this saves you a lot of typing, which you can then use to type up HN comments.
Objects and functions are different. An object retains state, a function should be stateless. Objects cannot be evaluated and do not have return values.
I think conflating data structures and objects is bad, and muddle the discussion. An app is mostly a pipeline of functions over an initial data structure.
I think you forgot the word mutable somewhere. A true Business Application(tm) has no mutable state that is not stored in the database, so all objects are immutable and therefore functions (except those dirty dirty data objects).
some_object.apply(method_name, param, ...) // sure looks like evaluation to me
You never mentioned immutable. If objects were immutable then yes you are correct.
I'm not sure what you mean by "true business application" but there is a transient form of mutable state that an object possesses in between processing a request and returning a response that is seperate from the state that the database holds. It is up to you whether you want that transient state to be mutable or not.
An object itself cannot be evaluated. Methods can be evaluated but not the object itself. Is your example referring to a specific language?... because in general objects are not functions.
Python disagrees with you. Given a python script with a single class. If you instantiate an object and try to "call" or "evaluate" it:
class A(object):
def __init__(self):
pass
x = A()
x()
you get this output to stderr:
Traceback (most recent call last):
File "python_temp.py", line 6, in <module>
x()
TypeError: 'A' object is not callable
Of course you can mess with the callable magic method, but that's more of a trick then a standard. You may be referring to how functions in python are implemented as callable objects rather than primitives. This is an implementation detail that is language specific, similar to how in javascript, functions are also classes.
In standard programming vernacular and practice, objects and functions are two different primitives. They are not the same thing. An object is a noun, a function is a verb, and just like their english grammar counter parts functions and objects are primitives because a Noun is not really a special kind of verb nor is a verb a special case of a noun.
DI is Dependency Injection, which is a $1,000 term for a $5 concept.
A Python class without DI:
class SomeClass(object):
def __init__(self):
self.someDependency = GetDependency()
A Python class WITH DI:
class SomeClass(object):
def __init__(self, dependency):
self.someDependency = dependency
...
That's it. DI is just explicitly passing ("injecting") a dependent object into an object, rather than requiring the object to call a function to get a reference/pointer to the dependency or make one.
I'm guessing Dependency Injection? In context meaning writing code that's easily testable, and writing lots of tests, which goes hand in hand with the other TDD/BDD buzzwords that job descriptions often throw out there.
