4 ms·

You really drank the coolaid I can see. I think dependency injection frameworks are a bad idea in general, and it seems as if the current trend goes against usi

• cjsuk 9y ago
  Where is this sudden DI framework hate coming from? It's just magic object glue that assembles everything based on contract. It's that or factory factory factories or sticky tape. Those are much worse. All the Java EE tech is just a set of contracts really with some canned implementations that magic object glue sticks together.
  • lolive 9y ago
    Factory factory factories... ;) http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
    • cjsuk 9y ago
      That was a nod to that article actually. No one does that now. Someone does some thinking, writes a strong interface, then builds the code behind it. There's usually only one implementation. The advantage comes at the testing phase when you have strong interfaces to mock. I can count on one hand the amount of things we do with multiple inplementations and that's mainly switching cache and file store implementations out depending on who paid for what.
      • barrkel 9y ago
        Testing using mocks usually (a) over-specifies the code under test (e.g. mandating method call order and call count), and (b) under-tests the integration across the boundary - i.e. there's no guarantee that the mock acts the same way as the concrete implementation. I prefer composition through more general abstractions like iterators, consumers, functors etc. where possible. With more general abstractions, there's both less need to mock (there are concrete implementations that are simple enough to use in tests) and the contract is trivial enough to be implemented consistently. Converting control flow (where modules interact through a rich protocol of method calls) into data flow (where modules interact by consuming data and producing data) promotes both a more functional style, and naturally leads to more testable code with fewer of the downsides of mocks. It also reduces the number of interface-implementation redundantly paired types throughout the system.
        • UK-AL 9y ago
          "mandating method call order and call count)" - Very few people use mocks like that. Most people use them glorified stubs for returning data. Personally these days I just in memory datastores.
          • barrkel 9y ago
            I have seldom seen a jMock Expectations clause without oneOf etc.
          • cjsuk 9y ago
            We do use mocks like that. How else do you test that a complex piece of logic doesn't try and perform the same operation twice, such as a trivial case of sending only one message to a queue? Without the assertion, you are left with an assumption, which from experience isn't reliable and keeps you up at night.
            • UK-AL 9y ago
              Because it makes refactoring very difficult. One of the original intentions of TDD and Unit testing was to make refactoring much easier. If you start testing the internals of function, it makes it very difficult to refactor without breaking tons and tons tests. We only test on publicly exposed functions, and check the changes on the data or external services. It means we can do major refactoring's of internals, keep public functions the same but tests will still pass. One of the biggest mistakes that happened was that kent beck was misinterpreted and Unit was considered a code unit, when really it means a unit of behaviour.
              • lolive 9y ago
                I don't disagree with your explanation. But the core point of objects is to bind a state and some method implementations. Mocking the state sounds mandatory to test the method implementations in such a paradigm. What you propose seems more like functional programming oriented testing.
            • 9y ago
    • LaGrange 9y ago
      Bet on a software engineering blog to try to make a point using bad paralels with, uh, murdering women.
      • cjsuk 9y ago
        I do believe that's actually a personality cult disguised as a software engineering blog
  • jononor 9y ago
    Stop putting code and data into the same object. It encourages way too stateful code and lots of cross-dependencies between code components. Pass around plain-old-data instead and the need for dependency injection is much less needed, just inject data instead when testing. And stop adding abstractions premptively, YAGNI.
    • cjsuk 9y ago
      These classes all sling value objects around. That's a separate thing.
• oweiler 9y ago
  As long as you program in Java DI is the best option you have if you want your code to be unit-testable.