Your DI framework is killing your code
blog.activelylazy.co.uk
Your DI framework is killing your code
1–10 of 59 posts
Re: Your DI framework is killing your code
#2My mind fused title "Your DI framework" into "DIY framework"
Re: Your DI framework is killing your code
#3For some reason this winds up being worse in the .net world than the java world. The main trouble I see with spring is not that it messes up your code but that people use stackoverflow to 'get things done' which leads to no overall strategy and thus mystery about how things get initialized.
Re: Your DI framework is killing your code
#4This is just the anemic vs rich domain model debate, the standard retort being https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain....
TL;DR: rich domain model causes an explosion of coupling (your User class is now coupled to your database, your screen, your rendering engine, your printer, etc, when all it really is is some user data). And the rich domain model simply breaks down when you need functionality on two objects (should it be user.render(engine) or engine.render(user); either way one of your domain objects needs to know some "private internals" of another). With the anemic domain model these problems don't exist.
Re: Your DI framework is killing your code
#5I can't help but disagree with so many of the things he says.
I won't even go into things like "Does your customer know what an OrderPriceStrategyFactory is for? No, then it’s not a real thing. Its some bullshit you made up.", but statements like "If we change how we contact customers then only the customer needs to change, not also the ReportBuilder" sound overly simplistic to me. The whole point would be that nothing needs to be changed. You just write a new ReportBuilder that implements the same contract/interface and switch the wiring. No changes in the existing ReportBuilder or Customer classes.
That, or maybe I'm just completely misunderstanding what I'm reading. Which isn't entirely impossible :-)
Re: Your DI framework is killing your code
#6Yet another time it comes up. But now, after functional programming being commonplace, we at least know the answer to the "why" question.
Consider the "classical OOP" method signature:
email.send()
vs "the anemic way"
emailSender.send(message: Email)
If there is only one way to send email (SMTP), things works fine. But let's assume we have to implement another way (e.g. Mailgun API). In the "anemic" case everything is simple: extract interface from EmailSender, add new implementation, all other method signatures remain unchanged. Refactorings are simple and can be done easily in any modern IDE. However, in "classical OOP" way, we have to do something like:
email.send(sender: EmailSender)
Which changes Email::send signature, which leads to breaking API changes and extensive manual refactoring of the entire codebase.
The "anemic way" had won because it is much more reusable and maintains API stability. Incidentally, this approach have smoothed the transition to functional languages — "NounVerber" objects became modules (collections of functions), and value objects became immutable data types.
Re: Your DI framework is killing your code
#7This is just the anemic vs rich domain model debate, the standard retort being https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain... . TL;DR: rich domain model causes an explosion of coupling (your User class is now coupled to your database, your screen, your rendering engine, your printer, etc, when all it really is is some user data). And the rich domain model simply breaks down when you need functionalit…
The coupling you mention was solved long before DI became popular. The service locator pattern isn't as transparent as DI but it solves the problem of course grained service dependencies.
Re: Your DI framework is killing your code
#8Yet another time it comes up. But now, after functional programming being commonplace, we at least know the answer to the "why" question. Consider the "classical OOP" method signature: email.send() vs "the anemic way" emailSender.send(message: Email) If there is only one way to send email (SMTP), things works fine. But let's assume we have to implement another way (e.g. Mailgun API). In the "anemic" case everything i…
> Which changes Email::send signature, which leads to breaking API changes and extensive manual refactoring of the entire codebase.
Only if you decide to change the signature, there are other ways to achieve the same result.
Re: Your DI framework is killing your code
#9I can't help but disagree with so many of the things he says. I won't even go into things like "Does your customer know what an OrderPriceStrategyFactory is for? No, then it’s not a real thing. Its some bullshit you made up.", but statements like "If we change how we contact customers then only the customer needs to change, not also the ReportBuilder" sound overly simplistic to me. The whole point would be that nothi…
I don't think the author makes a good case for the problem with, for example, noun-verbers, other than that they aren't very OO. If OO means putting lots and lots of state into objects, then I'm happy to be the lunatic fringe.
I like my objects as a unit of code organization and my value objects as simply that - an immutable representation of a value.
Re: Your DI framework is killing your code
#10"Almost certainly: if you’ve got value objects and noun-verbers, your design is rubbish."
If the code is readable, understandable, testable, and it does the job - who are you to say it's rubbish?