Printf(“%s %s”, dependency, injection)
fredrikholmqvist.com
fredrikholmqvist.com
This was written after comparing a ~300K SLOC Go project to it's original ~800K SLOC Java project at work, that we've rewritten over the course of a year or so.
In the Go version, test coverage is floating around 90-95%. Performance, and memory use especially, is drastically better. This is from lessons learned, where a large part of those lessons meant reducing this type of 1990s XP/Agile/SOLID style of constant indirections and pass through classes.
Yes, the main files where startup allocation happens are huge, but it's all in one file (per service) and can be easily grokked with IntelliSense and general code navigation features.
In the Java version, every folder had a large section of subfolders with files that pointed to other files that perhaps did something besides calling other objects. Startup was horrible, memory consumption was high and tests were somehow more verbose than Go (which are already a mouthful).
I want to point out that I love SmallTalk, and feel that this style makes sense in that environment. For Java/Microsoft Java, this style is IMO not worth the effort for neither developers nor codebase.
Interesting discussions in this thread already, thank you <3
What does eXtreme Programming or Agile have to do with how you pass messages in code?
Perhaps it's something about my area, but this style is standard idiomatic Java/C#.
EDIT: And the opposite statement is (perhaps more) true for Go. Adopting IBeanProxyFactory-type of stuff in there is beyond unidiomatic.
I think it’s telling that Go, Rust, as well as more inspired stuff in later editions of C++/Java/C# all seem to be demonstrating that nominal inheritance-first polymorphism is not the only or always the best maze of abstraction for getting to a concrete dispatch from type A to type B in imperative-feeling languages.
How much of the improvement is attributable to the rewrite and lessons learned and how much is attributable to using the backend language du jour?
It also helps if the language idiomatically nudges you in the right direction.
Indirection tends to be minimized in Go, similar to C, and encourages solving your immediate problem.
Comparatively, Java and C++ encourages you to design/grab for reuse first, opting for flexibility.
IME Java devs will write idiomatic OOP in this style, just like Lispers will fiddle with macros. For us, picking Go helped signal that we wanted people who wrote procedural, direct-first code.
> I want to point out that I love SmallTalk, and feel that this style makes sense in that environment.
Seems like 2 different things are being conflated, possibly because much of that XP TDD stuff was done by some prominent Smalltalkers.
Test first, send a messages to objects, or inject something smarter.
... and I loved it. Talking to a living thing via messages felt a lot like Erlang or Lisp. I don't get that vibe from Java/C#, despite similarities.
I should probably pick up SmallTalk again. Any recommendations?
I don’t want to assume your reply was intended to be rude. I think they’re asking for recommendations on anything that might help/guide them picking up SmallTalk again.
First you imply my question was rude, and then you call me a jerk, and then you call me mean.
I did not dismiss the request, I gave a recommendation.
In this case, I would want to learn more just for the fun of it, like learning to play an instrument, holding off effecting the world for now.
The first Smalltalk implementation I used was bought because I had already implemented a proof-of-concept prototype on a spreadsheet (Lotus 123 iirc).
As-it-happens I have no experience with Smalltalk-as-a-hobby.
class MyService {
ILogger<MyService> _logger
MyService(ILogger<MyService> logger) {
this._logger = logger;
}Making it a monumental PITA to use without the associated Jungle: The chosen DI framework. Why is the ILogger generic? Because of the DI framework, so it can create a logger that corresponds only to this type.
We're literally writing code to keep the framework happy.
Even though there are no other implementations.
Why? Seems to boil down to "our language / environment / DI system / mocking framework is incapable of working unless you do it this way.
Yet more cognitive and implementational waste.
Hence you can't have function composition, instead you get dependency injection, with an extra layer of XML files in most frameworks to allow injecting different stuff without recompiling the classes without access to the source, or just obviating the need to recompile.
DI is a nice concept, and is used to solve a real problem of declaratively configuring closed-source code. I bet that declarative DI implemented for CL or Scheme would look more compact and neat than the typical Java approach.
Why do you think the Gang of Four book uses Smalltalk and C++ without any traces from Java?
But, unlike Java, Smalltalk is (utterly) dynamic, and you don't have to declare a class for your code block. In Java, you had to dance that dance, until lambdas were introduced to let the compiler do that for you.
"Smalltalk blocks and closures origin and evolution" Juan Escalada
And no lambdas are not implemented that way, rather they take advantage of invokedynamic.
"Every object in Smalltalk, even a lowly integer, has a set of messages, a protocol, that defines the explicit communication to which that object can respond. Internally, objects may have local storage and access to other shared information which comprise the implicit context of all communication."
p290 Byte Magazine 1981
http://worrydream.com/refs/Ingalls%20-%20Design%20Principles...
> > > … instead of a function…
Instead of a function, a message.
Let's take that literally —
perform: aSymbol with: anObject
Answer the result of sending a binary message
to the receiver with selector aSymbol and argument
anObject. Report an error if the number of arguments
expected by the selector is not one.
https://rmod-files.lille.inria.fr/FreeBooks/SmalltalkVTutori... )
Last-time I remember using those #perform methods, it was for testing — walking the code sending arbitrary messages and and arguments.
"Design Patterns: Elements of Reusable Object-Oriented Software"
You forgot to check the publishing date,
https://en.wikipedia.org/wiki/Design_Patterns
Publication date => 1994
https://en.wikipedia.org/wiki/Java_(programming_language)
First public release => 1995
No I did not.
You don't. I do.
The authors’ statement is clear.
… perhaps came later, with embellishment
DI allows a generic runtime to instantiate and compose component graphs [via declarative initialization contexts]. The idea was we'd have reusable components. Somewhere along the line came Spring ("J2EE is too complex" lol) and before you knew it, any old application was using DI and now (per a scan of comments in this thread) everyone is quite confused what is the purpose of "passing variables to your functions" in this obscure manner.
> NEO was re-positioned as a Java system with the introduction of the "Joe" framework,[2] but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans
https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhe...
And we did just the same with objects factories and directories on the listed technologies.
Perhaps "What people like to blame Java for…" is how it was required to be done in Java.
Perhaps Java became a victim of enterprise culture, just like nowadays everyone is doing system level DI with Kubernetes orchestrations and WebAPI?
When those are the appropriate search keywords.
No, the thing that stopped Java having function composition was the lack of (ergonomic) closures. But it got closures in 2014, and now you can do function composition. Despite the fact that it still doesn't have top-level functions.
I still don't really understand where all the XML came from, or the wave of equally unnecessary annotation-based dependency injection that came afterwards. There has been a dream of "write reusable components, then compose them to form applications" that has been very strong in Java right from the outset, and i tentatively think that people just didn't get that you could do the composition in code.
Now you can have lambdas, and they go to a generated class as methods, so that the JVM could execute them.
Where XML came from: how do you configure WebSphere in 2000? XML was all the rage since mid-1990s. It had a ton of advantages, back when you did not have JSON, YAML, or TOML.
Yeah, Java does that to people. It's such a limited language that it becomes impossible to conceive of better ways to solve problems.
Apparently it's come a long way since Java 6, it's even broken backwards compatibility, never expected that to happen. It's adopted many functional concepts in the usual insanely verbose Java style. Still a very limited language though, especially when compared to real functional and object-oriented languages. It's limited even when compared to C.
https://news.ycombinator.com/item?id=16143918
> The key point here is our programmers are Googlers, they’re not researchers.
> They’re not capable of understanding a brilliant language
> So, the language that we give them has to be easy for them to understand
It's pretty insulting in my opinion. Imagine being a programmer at Google, likely one of the best jobs in tech, and reading this.
Java does support lambda expressions.
Also, the fact that in Java everything is a class is something that cuts both ways. As you're already going to have classes, you can have your pure functions as static member functions from any class that suits your fancy. That pretty much works as a function within a namespace.
The final is to avoid some mistakes, but they are still effectively closures.
I wonder if such contracts are are solved now like in other languages with typed function references/pointers - C++/Go/etc (syntactic sugar is enough, doesn't have to be variadic generics). I remember 'var' was introduced so I suppose that worked if the closure type could be inferred.
I would take that over Go's special syntax for map any day as I now have the power to create my own functional interfaces and plug them into Java's standard library.
The problem of the static method as a function is not the implementation, it's the ergonomics. It's not terrible, but certainly it is wordy. I agree that a conservative approach to adding any new syntax is wise for a project of such an industry footprint. But the wordiness is what the original article points at, not any logical design faults.
You can pass static methods as parameters in at least C++, Python and Javascript.
Unfortunately, methods are not first-class objects in Java (while classes, with .class, are).
Even if you have static methods, you still need to use this stuff because they are methods, not functions. Classes aren't objects so they can't implement interfaces or be passed around as parameters. Gotta make things like singletons and factories because of this just so you can essentially pass a function pointer around. There's names for stuff that in better languages just happens naturally without people even thinking about it.
In SML, a piece of code depends on interfaces, and exposes an interface of it's own. Functors bind together pieces of code with appropriately matching interfaces.
[1]: https://www.haskell.org/hugs/pages/users_guide/implicit-para...
* Implicit parameters are a language extension, not part of standard Haskell (although extensions are so ubiquitously used that this does not matter much).
* Implicit parameters are rarely used[0]. I would not be surprised if most experienced Haskell programmers have never used them, and while they may know they exist, they might not even remember the syntax or semantics. I belong to that category myself. In Haskell, type classes tend to be used for what other languages might do with implicit parameters.
[0]: https://gist.github.com/atondwal/ee869b951b5cf9b6653f7deda0b...
more on the topic:
http://blog.ezyang.com/2020/08/dynamic-scoping-is-an-effect-...
not sure it's a really good explanation. You aren't the one giving the arguments to the function, it's the framework in which you are opting into which is going to do that.
Imagine you are writing a software for, say, rescaling images. You have hard requirements:
- You want people to be able to provide their own rescaling code as external plug-ins / DLLs which you do not know about when compiling your host.
- You want your host software to provide the memory allocation primitives to the DLLs so that they can allocate memory for the rescaled images in a way that you will have control of in the host software.
- The memory allocator being used can itself be a plug-in too, that the user can choose at runtime in e.g. a GUI settings panel.
(Alternatively, for something more Haskell specific, you can also write your stuff generically against a typeclass, and let people provide their own implementations.)
Congrats on reinventing DI ! Guess what your array of struct reacale_plugin* is called, hint, it starts with DI and ends with container
People invented this because Java and its friends made it so insanely hard to do it that you needed to invent convoluted techniques to accomplish the same task.
here's one: https://stackoverflow.com/questions/5925270/how-to-do-depend...
If you're writing a library that does things that involve talking to a database:
- Not DI: You `import Database.PostgreSQL.Simple` and your function(s) take the appropriate arguments to pass to postgresql-simple.
- DI: Rather than you `import`ing a library to talk to a database, you take an argument that is an object/function (a partially-applied `connectPostgreSQL`? an instance of a typeclass?) that you use to talk to the database.
(IDK if the various SQL libraries for Haskell are compatible enough with each other to make that example particularly realistic)
Instead of using a library, you take an implementation as an argument. That's all DI is.
Here's a Python example without DI:
class MyClient:
def __init__(self):
self.http_client = httpx.Client()
class MyClient:
def __init__(self, http_client=None):
self.http_client = self.http_client or httpx.Client() self.http_client = self.http_client or httpx.Client()
self.http_client = http_client or httpx.Client()
class MyClient(HTTPClient):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
def do_some_networking(self, arg):
super().http_get("server", arg)
class MyClientWithDI(MyClient, MyHTTPClient):
pass
client = MyClientWithDI()
# Will call MyHTTPClient's http_get
client.do_some_networking("/status") class MyThreadImpl:
def run(self):
do_stuff()
class MyThread(Thread, MyThreadImpl):
passNot sure? Eg Haskell typeclasses (and that includes monads!) could mostly be replaced by just passing arguments around (basically a bit like a vtable in C++). But it would make the ergonomics almost unusable.
Of course, many real world functional programmers (or wanabe functional programmers) like to make fun of OOP.
That said, I think Scala did that, separating module/package level parameters and functional parameters can help designing/thinking.
my 2 cents
But yeah, you probably get something like 80% of the benefit of modern functional programming from just first-class functions, algebraic data types (and pattern matching over them), and immutability by default.
You can call it "Static Initialization Order Fiasco" in C++ or just general dependency handling, but a big problem in any sort of bigger server or framework is just setting up all the parts that make it run. If your handler A depends on B and C which in turn depend on D, E and F each of which can have their own dependencies, writing and maintaining the correct boilerplate that sets them up along the critical path is a problem best left for the fricking computer to figure out itself.
class Service1 { ... }
class Service2 {
private Service2 service2;
void setService2(...)
void afterPropertiesSet() { requireNonNull(service2, "service2"); }
}
main() {
Service1 service1 = new Service1();
Service1 service2 = new Service2();
...
service2.setService1(service1);
...
service1.afterPropertiesSet();
service2.afterPropertiesSet();
...
First off you aren't using interfaces, which makes it unclear how you're writing test versions of your classes, but also you're setting up a massive foot gun by having a dependancy-injector with completely uncoupled consumers later in that same class. For example if I have multiple setService (e.g. serviceA, serviceB, and serviceC) and I want to call .afterPropertiesSet(), how do I know which it depends on externally? Do I have to go inspect afterPropertiesSet()'s code? Or just wait for an exception to be thrown in a Run<->Throw<->Fix endless cycle? Eww.
There's a very, very, good reason why all DI frameworks have you use interfaces and the class's constructor to inject. Because if injection happens during class construction, every call after can make the assumption those things exist. By decoupling that assumption from those calls, you've created a development hell (i.e. this is an unmaintainable mess).
There're two good ways to do DI:
- During class construction. They then always exist in the class's scope.
- Every method call individually takes in all explicit dependencies (e.g. GetMagic(iDatabase database, iDateTime dateTime, ...)).
Your example is neither of those.
Use interfaces if you want, there are different approaches to testing. Some classes are fine to inject as they are. Some classes are fine to mock with libraries like Mockito. And sometimes interfaces makes sense.
> For example if I have multiple setService (e.g. serviceA, serviceB, and serviceC) and I want to call .afterPropertiesSet(), how do I know which it depends on externally?
I'm not sure I follow you. You just wrote that class, surely you know what dependencies you need.
> There's a very, very, good reason why all DI frameworks have you use interfaces and the class's constructor to inject.
You're wrong here. I don't know a single DI framework that forces you to use interfaces and constructors. Setter injection or field injection is supported everywhere, at least in Java world.
> By decoupling that assumption from those calls, you've created a development hell (i.e. this is an unmaintainable mess).
I used that approach. It works good and it scales without issues with quite complex dependency chains. One issue is a little bit of mundane work, but it's not a lot and simplicity worth it.
> There're two good ways to do DI:
> - During class construction. They then always exist in the class's scope.
Constructor injection is terrible approach to use without DI framework. You'll need to move your initialization code around almost every time your dependencies change. You inevitably will invent yet another DI framework, buggy and incomplete and at this point you lost. Also it does not allow for circular dependencies, which sometimes are necessary. Another point is that Java does not have named parameters and long constructor calls are hard to read (recent Idea improves that a little bit with inlay hints, though).
> - Every method call individually takes in all explicit dependencies (e.g. GetMagic(iDatabase database, iDateTime dateTime, ...)).
That's not a dependency injection, as it requires to pass dependencies through every call chain. If you suddenly need some service deep inside your chain call, you have to change all functions which lead to that call. It might be a suitable approach for some 1000-LoC one-file program, but it does not scale.
Hmm, I feel they actually are very similar. The map function doesn't care what the mapping function is, as long as it's something it can call on each element returning something, it can do it's job. Same with DI in enterprise apps, my db-service don't care if it's a in-memory-test-db or postgres being injected, as long as the connector allows it to call sql methods on it.
In Ruby one of my favourite calling conventions is to pass self to the methods, rather than the constructor, of collaborator objects.
To write functional code that looks a bit more like OOP, I guess you want 'open recursion'. Open recursion is what allows you to do the equivalent of overwriting methods in subclasses when doing FP.
See eg https://www.cs.ox.ac.uk/people/ralf.hinze/talks/Open.pdf or https://journal.stuffwithstuff.com/2013/08/26/what-is-open-r...
Passing interfaces to functions directly instead of at construction time sounds like a leaky abstraction, because I as client should not care that some function relies on another function as an implementation detail. Functional languages solve it with currying and in this context I don't see semantic difference between currying and saving a dependency in a class/struct in OOP languages, they're analogous.
Snark aside (but the sentence above is really what happened at $PREVIOUS_JOB), I think there is value in assigning dependencies declaratively, but I think it is better done in a proper programming language (with IDE support, compile-time error checking, proper parametrization and escape to procedural code, testing, etc.), not in an xml file (and no, json or yaml are not better).
I think the "injection" part is more literal in frameworks where the injection-container inserts references into objects in a "scope". For example in hibernate, dependencies could be given in annotations, and did not have to given in the constructor.
DI frameworks also provide aspect-oriented-programming services (transactionality, logging...). Doing that with plain functions in an arity-polymorphic way is possible, but not completely trivial, in my (Haskell) experience. http://web.cecs.pdx.edu/~ntc2/haskell-decorator-paper.pdf
> They called it Select as to not arouse any suspicion, hinting that this was just typed SQL, not functional programming. Sneaky sneaky.
Haha.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Essential!
If it's your code, and yours alone, just do whatever.
Simple and terse works great for small code-bases, developed by small teams with like-minded people that have similar tastes and backgrounds. Often, such small groups of people communicate so well with eachother that they also share an excellent common understanding of what they build across the stack.
At some point both the team and the code-base will start growing. You'll need strong, opinionated frameworks in-place for accomodating this growth. Without those guardrails in-place, there's nothing preventing the code-base from growing in a thousand different directions.
Often times a project starts without those frameworks in-place, because it's so much easier to jump straight into business logic and not waste any time on pesky factories, interfaces and enums. By the time new people come in and start contributing - it's already too late and you've racked up too much code to start fresh - might as-well just keep piling on. A snowball effect.
Dependency Injection as presented in the "hold on to your hats" section of the article may seem ugly and overcomplicated - but is one of those patterns used to hold large codebase to a unified, repeatable and persistent standard. "Fun" was never a part of the equation.
One of my first languages was .net and I was never able to really understand DI in that context that well.
Actually using javascript and ducktyping made me understand what it actually was.
I remember a .net job interview where I had to write a micro-service and opted to construct the dependency graph in the main function initialising "all" the classes there. Instead of discussing the pro's and con's of that approach they berated me for not using a DI framework (No I did not land that job, but in hindsight it was the most expensive job interview I've ever had. The room was filled with 8 developers going over my code).
The main thing the article glosses over is state. something people with a functional background hide from. But if you look at something like the httpclient in .net. I think it took the .net world like 10 years to start using the httpclient properly. Scope and lifetime of those kind of objects are important. managing connection pools, retry state, throttling or the incoming http request. DI does make that kind of thing easieR (I'm not saying it makes it better)
Look at clojure's component(https://github.com/stuartsierra/component), I'm not a clojure expert by far. But it is kinda DI/IOC in a functional language.
In closing we can agree that it is underused in the right places and overused in the wrong ones.
I’d be inclined to agree that you probably don’t need that in your hobby or research projects, but if you ever worked on a serious application with test mocks, production/beta environments, hundreds of libraries that need to play in tandem, and a team of several developers, not having proper DI kills your productivity.
In 2020 we served roughly 4 billion purchases on that platform :)
But the comment was about your examples, and they are not great - they appear to be created to show how useless or overcomplicated DI is. And it is overcomplicated - in your toy examples.
However, there are plenty of better examples on the net of the benefits of DI, but in order to actually show any usefulness they either have to be large, or depend on the readers to "extrapolate" to larger/more complicated code bases.
The first draft dragged on as I tried to give a concrete example (API + Service + DB CRUD) in various implementations (Erlang gen_servers, CL CLOS, JS currying, C# with/out automated DI etc). I have a hard time tying my lose ends when writing, so I opted by a simpler example, perhaps swinging the bell too far the other way.
Thank you (all) for pointing it out, I missed it completely :)
My comment above was to exemplify that there perhaps is a span between everyone-is-wrong (by some definition of everyone) and the-author-is-inexperienced.
In Elixir you could pass either a function or a module and defines an interface (the @callback notation). Maybe frameworks are then more a symptoms to a deeper problem in the language than a solution?
It's like a few years ago where you could listen to the same argument regarding XML. Now most of the systems use JSON in 90% of cases and for these cases it's better.
Why? I'm not sure Garbage Collector cares if it's dynamically resolved or not.
Also, not all DI is runtime. E.g. Dagger2 uses build-time injection, i.e. it just generates glue code, which is easy on JIT or AOT compilation.