3 ms·

SOLID is rather old, and never really grabbed me that much. Well, rather, I kinda agreed with it (but I had been in OOP for about a decade before it came along

SOLID is rather old, and never really grabbed me that much. Well, rather, I kinda agreed with it (but I had been in OOP for about a decade before it came along) for a bit, but no longer. Most of it is rather obvious, and I find the terms just buzzwords. "Dependency Injection" particularly drives me crazy, as we've been passing in references to objects forever, and suddenly we need a Special Term for it. What next, instead of pointers we call them Dependency Actors? I also agree that I'm tired of tiny classes and tiny functions. I went on a rant to my coworkers the other day about them, after spending an afternoon figuring out how some code works that fully believed in small functions. Nothing makes 100 lines of code more readable than splitting them across 100 functions in 10 classes in 10 files! /s I agree with another poster, though, that VisualWorks Smalltalk made it a lot more palatable. I'd honestly really like to try a system that treats a program as a database of functions rather than a directory structure of files. I don't think the directory structure adds anything that a tagging system couldn't do.

Matthias247 7y ago
> "Dependency Injection" particularly drives me crazy, as we've been passing in references to objects forever Might have been old to you, but not to everyone. I have seen plenty of codebases which inject nothing and where all objects create their dependencies themself. Lower level code is especially susceptibly to this - the amount if C code that I've seen that made use of some kind of DI tends to go towards zero. And with that often also the amount of tests that are available for the codebase (with claims like: This is not testable). I find the term "Dependency Injection" also still unnatural and academic, but I really like the core idea, which isn't that hard to teach (pass dependencies instead of creating them yourself). Whether one also needs DI frameworks is another topic, on which I have no strong opinion.
- blub 7y ago
  The whole thing is just a pretentious sounding term for the extremely basic idea of passing parameters. No dependencies are being inverted. The name is just complete crap.
  - gilbetron 7y ago
    This. It makes it sound like more than it is, and while the basic idea should be taught (briefly), it isn't some amazing concept worthy of enshrining in some holy Acronym.

Matthias247 7y ago

> "Dependency Injection" particularly drives me crazy, as we've been passing in references to objects forever Might have been old to you, but not to everyone. I have seen plenty of codebases which inject nothing and where all objects create their dependencies themself. Lower level code is especially susceptibly to this - the amount if C code that I've seen that made use of some kind of DI tends to go towards zero. And with that often also the amount of tests that are available for the codebase (with claims like: This is not testable). I find the term "Dependency Injection" also still unnatural and academic, but I really like the core idea, which isn't that hard to teach (pass dependencies instead of creating them yourself). Whether one also needs DI frameworks is another topic, on which I have no strong opinion.

blub 7y ago
The whole thing is just a pretentious sounding term for the extremely basic idea of passing parameters. No dependencies are being inverted. The name is just complete crap.
- gilbetron 7y ago
  This. It makes it sound like more than it is, and while the basic idea should be taught (briefly), it isn't some amazing concept worthy of enshrining in some holy Acronym.