Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your DI framework is killing your code

blog.activelylazy.co.uk

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Your DI framework is killing your code

#21

Post by donatj »

My comments from the page, awaiting authorization:

"See, what you are suggesting is actually a strong violation of the single responsibility principle as well as separation of concerns. This is exactly like the code I used to write. While it really is easier to manage when it's small, it's a naive approach that doesn't scale well.

In a real life example of what you are suggesting, our User and Building classes for instance ended up over 10,000 lines long, doing things even just tangentially related to their parents. The real kickers were the cross business object ones who required more than one. Is it on Class X or Class Y? Sometimes it would end up on both accidentally causing the angels to cry.

About two years ago we started a massive rewrite, and now we have lots of small consice objects that perform very specific tasks. They're logical, organized and dependency injected. I would never wish the reverse on anyone."

Re: Your DI framework is killing your code

#22

Post by zaphar »

I'm not a big fan of DI frameworks but none of the arguments in this article ring true for me.

His proposals for how OO should work are half the reason I started shifting toward functional languages years ago. OO learning from Functional is a good not bad thing.

Re: Your DI framework is killing your code

#23

Post by anthony_d »

jasonlfunk wrote: post #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?

I think the problem is that OO is a term that people don't understand anymore. The author is right about OO principles and the fact that most people don't follow the traditional usage. The thing is that good OO isn't actually good code.

The world has moved away from strict OO because it's not very maintainable.

Re: Your DI framework is killing your code

#24

Post by Asbostos »

How come OOP was supposed to be the best way to code and now we need dependency injection to make it practical? Does that mean that before DI, OOP was never being done properly? It was a bad idea all along and everybody thought it was just their poor OO skill that made them unable to design programs that met all the requirements?

Re: Your DI framework is killing your code

#26

Post by mistermann »

atemerev wrote: post #11
orf wrote: post #8

Earlier quoted context omitted.

> 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.

For example?

Couldn't you just add a new SendMethod optional parameter defaulted to the method that was used prior to the refactoring? No breaking API changes, no extensive manual refactoring of the entire codebase, as far as I can tell. This is how I always did refactoring for years, it's immediately obvious to support developers wtf is going on, and there's no requirement to have any "complicated" architecture on every single object in your entire application. Instead, the code largely resembles the simplicity of the real world being modeled.

Is this approach is so dangerous (as we're constantly told) why has it never caused me any problems? Maybe I'm missing something but I've never read an article that explains what it is I'm missing in a way that clicks.

Re: Your DI framework is killing your code

#27

Post by verinus »

imho a very shallow understanding of oo. the arguments are only true for very simple models. when you have operations that manipulate multiple objects or have some other cross cutting concerns these models completely break down.

on the other hand: IoC containers try so solve a let-down of oo...we have to come up with something better- functional programming?

Re: Your DI framework is killing your code

#28

Post by facorreia »

anthony_d wrote: post #7
daxfohl wrote: post #4

This 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.

You mean "coarse-grained", right?

Re: Your DI framework is killing your code

#29

Post by rescripting »

donatj wrote: post #21

My comments from the page, awaiting authorization: "See, what you are suggesting is actually a strong violation of the single responsibility principle as well as separation of concerns. This is exactly like the code I used to write. While it really is easier to manage when it's small, it's a naive approach that doesn't scale well. In a real life example of what you are suggesting, our User and Building classes for in…

Yes! I was lucky enough to start a green-field project recently and basically did exactly what the author is advocating against. So far it's been the most extendable, easy to read and easy to maintain project I've worked on.

The author briefly mentions the Single Responsibility Principle and then tramples all over it, suggesting you put your 'code close to your data', shoving your verbs onto your models? Good luck ever refactoring. You'll have orphaned properties and methods that people are afraid to remove because they may anger the gods. You'll have flags, flags everywhere to control how your model does its work. Give me small, swappable, testable noun-verb classes any day of the week.

Re: Your DI framework is killing your code

#30

Post by gwbas1c »

The author suggests a naive approach to object oriented programming. When all functionality is a method of the data it represents, these objects become hideously complicated and unmaintainable.

An example is comparing Objective C's string class, to .Net's. In objective C, path manipulation methods are on the string object itself; but in .Net, path manipulation methods are static methods in the Path class.

The .Net approach is better. Why? Do all strings represent paths? No. There's an unlimited number of ways and reasons for manipulating strings; and making them all methods of the string class is unsustainable.

Post reply on HN