5 ms·

Took me a long time to grok OOP and OOD (was introduced to OOP in '91). At first I thought I knew it, and then realized I didn't. Plane into the side of the mo

Took me a long time to grok OOP and OOD (was introduced to OOP in '91). At first I thought I knew it, and then realized I didn't. Plane into the side of the mountain, no survivors, call off the search. Which is when I really started to learn (around '96/97). And now I love it. Until I come across people who always start by defining an interface first and then think about what might follow. And dependency injection. Holy priceless collection of Etruscan snoods DI makes me want to gouge out my eyeballs with a rusty cork screw. Like I said though I love it and today my happy land is about 80% OOP and 20% everything else.

hacker_9 8y ago
DI is bad, what? So how are you writing tests then.
- tonyedgecombe 8y ago
  I always though dependency injection was an inevitable product of over zealous testing. As soon as someone says we need to test 100% of the code in our UI that is where you end up.
  - hacker_9 8y ago
    No it's just an inevitable product of 'testing'. It's a simple way to enable and disable dependencies. There is literally no better way, apart from not having any dependencies in the first place of course.
- Spearchucker 8y ago
  Like in procedural languages I write my own harnesses as needed. Because DI adds complexity. And for testing all DI does is make testing easier. You end up shipping all that complexity or you refactor your ship code. To be fair that might be acceptable to many in a typical corporate environment.
  - vietjtnguyen 8y ago
    What do you mean by DI? I find DI is an overloaded term.
    - ahansen 8y ago
      In this context I believe he is referring to dependency injection.
      - vietjtnguyen 8y ago
        I guess I meant to ask what they mean by dependency injection. A bare version is just passing dependencies as arguments and I can't imagine what is so egregious about that. Maybe they mean something more complicated?
        steveklabnik 8y ago
        Given "I write my own harnesses as needed", I read the parent as talking about DI frameworks, not the general concept of DI. https://en.wikipedia.org/wiki/Dependency_injection#Dependency_injection_frameworks https://en.wikipedia.org/wiki/Dependency_injection#Dependenc...
  - hacker_9 8y ago
    Well you are going to need to deal with your dependencies eventually. Unless you are just end2end testing, and not doing any unit tests. In that case good luck finding your bugs when they appear. Or perhaps you write 'if (mode == "test")' everywhere :)
- MarkMc 8y ago
  By letting the application load all required components into memory before running the test(s). If Component A needs Component B which needs Component C, they all get loaded as they would in production (ie. without mocks). If this means that almost the whole application gets loaded to run a single test, so be it. The only time this approach is really a problem is when doing slow calls such as I/O - eg. writing to the database. In such cases you can easily switch to an in-memory database or use a factory pattern (which is kind of like a hand-rolled mock). It's true that an error in say Component C may generate many failures in test of for other components, but in practice that's not really a problem. Just pick one of the test failures and drill down until you find the root cause - fixing that cause will magically fix the other 55 test failures.
DanielBMarkham 8y ago
The thing I love about OOA/D/P is that it is a useful and productive way of thinking about things. It's probably even the most natural and intuitive way of thinking about them. Plato wasn't a C++ programmer, but classes and interfaces are direct descendants of his work 2k+ years ago. When I first fell in love with OO there was a time that I felt that there wasn't a problem in the world I couldn't solve using it. That moment it finally "clicked", and all the lights came on? Wow! One of the best intellectual experiences of my life. It changed everything. I was right about being able to do anything with it. What I was wrong about was how some things are more difficult than others. Rules-based systems, for instance, get abstracted away into a sort of gobbledygook in OO. Scripting is uglier than it should be. Then I had a similar realization about FP. It took much, much longer and there was no dramatic moment, but the impact was just as huge. It was a new way of thinking about and solving problems. It has it's own edge cases and antipatterns, of course, just like OO. I wonder what the next A-Ha! change will be? TLA+? Is there a system of thinking around morals and values as it applies to problem solving, as Kant and others thought? Beats me. I hope I get to find out.
- barrkel 8y ago
  Data flow. Closely related to functional programming, and also relational algebra. Different variants, whether reactive, push vs pull, streaming vs batch, restartable, etc.
ilovecaching 8y ago
DI is an essential feature of functional programming, and it's incredibly simple to understand. You're real issue is that OOP is a terrible, broken model that can only model a pattern like DI with a high degree of complexity.

hacker_9 8y ago

DI is bad, what? So how are you writing tests then.

tonyedgecombe 8y ago
I always though dependency injection was an inevitable product of over zealous testing. As soon as someone says we need to test 100% of the code in our UI that is where you end up.
- hacker_9 8y ago
  No it's just an inevitable product of 'testing'. It's a simple way to enable and disable dependencies. There is literally no better way, apart from not having any dependencies in the first place of course.
Spearchucker 8y ago
Like in procedural languages I write my own harnesses as needed. Because DI adds complexity. And for testing all DI does is make testing easier. You end up shipping all that complexity or you refactor your ship code. To be fair that might be acceptable to many in a typical corporate environment.
- vietjtnguyen 8y ago
  What do you mean by DI? I find DI is an overloaded term.
  - ahansen 8y ago
    In this context I believe he is referring to dependency injection.
    - vietjtnguyen 8y ago
      I guess I meant to ask what they mean by dependency injection. A bare version is just passing dependencies as arguments and I can't imagine what is so egregious about that. Maybe they mean something more complicated?
      - steveklabnik 8y ago
        Given "I write my own harnesses as needed", I read the parent as talking about DI frameworks, not the general concept of DI. https://en.wikipedia.org/wiki/Dependency_injection#Dependency_injection_frameworks https://en.wikipedia.org/wiki/Dependency_injection#Dependenc...
- hacker_9 8y ago
  Well you are going to need to deal with your dependencies eventually. Unless you are just end2end testing, and not doing any unit tests. In that case good luck finding your bugs when they appear. Or perhaps you write 'if (mode == "test")' everywhere :)
MarkMc 8y ago
By letting the application load all required components into memory before running the test(s). If Component A needs Component B which needs Component C, they all get loaded as they would in production (ie. without mocks). If this means that almost the whole application gets loaded to run a single test, so be it. The only time this approach is really a problem is when doing slow calls such as I/O - eg. writing to the database. In such cases you can easily switch to an in-memory database or use a factory pattern (which is kind of like a hand-rolled mock). It's true that an error in say Component C may generate many failures in test of for other components, but in practice that's not really a problem. Just pick one of the test failures and drill down until you find the root cause - fixing that cause will magically fix the other 55 test failures.

DanielBMarkham 8y ago

The thing I love about OOA/D/P is that it is a useful and productive way of thinking about things. It's probably even the most natural and intuitive way of thinking about them. Plato wasn't a C++ programmer, but classes and interfaces are direct descendants of his work 2k+ years ago. When I first fell in love with OO there was a time that I felt that there wasn't a problem in the world I couldn't solve using it. That moment it finally "clicked", and all the lights came on? Wow! One of the best intellectual experiences of my life. It changed everything. I was right about being able to do anything with it. What I was wrong about was how some things are more difficult than others. Rules-based systems, for instance, get abstracted away into a sort of gobbledygook in OO. Scripting is uglier than it should be. Then I had a similar realization about FP. It took much, much longer and there was no dramatic moment, but the impact was just as huge. It was a new way of thinking about and solving problems. It has it's own edge cases and antipatterns, of course, just like OO. I wonder what the next A-Ha! change will be? TLA+? Is there a system of thinking around morals and values as it applies to problem solving, as Kant and others thought? Beats me. I hope I get to find out.

barrkel 8y ago
Data flow. Closely related to functional programming, and also relational algebra. Different variants, whether reactive, push vs pull, streaming vs batch, restartable, etc.

ilovecaching 8y ago

DI is an essential feature of functional programming, and it's incredibly simple to understand. You're real issue is that OOP is a terrible, broken model that can only model a pattern like DI with a high degree of complexity.