• Solemarc@lemmy.world
    link
    fedilink
    arrow-up
    8
    arrow-down
    2
    ·
    6 months ago

    At work we have a lot of old monolithic OOP PHP code. Dependency injection has been the new way to do things since before I started and it’s basically never used anywhere.

    I assume most people just find it easier to create a new class instance where it’s needed.

    I’ve never really seen a case where I think, “dependency injection would be amazing here” I assume there is a case otherwise it wouldn’t exist.

    • lorty@lemmygrad.ml
      link
      fedilink
      arrow-up
      3
      ·
      6 months ago

      Isn’t the point of injecting classes so that you don’t have tens of instances of the same class in memory?

      • epyon22@programming.dev
        link
        fedilink
        arrow-up
        12
        ·
        6 months ago

        When we implemented it significantly improved our ability to write unit tests. It also allowed us to make more modular code due to the default of every class having an interface. So I’m all for it.

        • porgamrer@programming.dev
          link
          fedilink
          arrow-up
          8
          arrow-down
          1
          ·
          edit-2
          6 months ago

          In my opinion dependency injection solves a problem that doesn’t need to exist, and does it by adding even more obfuscation and complexity.

          The problem is that the original gang of four design patterns had very little to say about managing effects. In old java code things like network and file IO often happen deep inside the object graph, hidden behind multiple impenetrable abstractions such that it’s impossible to run the logic without triggering the effect.

          The wrong solution is to add even more obfuscation and abstraction, so that you can inject replacement classes deep inside the object graph where the effects happen. it solves the immediate problem of implementing tests, but makes everything else worse and more confusing.

          The right solution is to surface all your effects at the top level of the call graph. The logic only generates data, and passes it back up to the top level of the program. The top level code then decides whether to feed this data into an effectful operation. Now all your code is easier to reason about, and in you can easily test the logic without triggering unwanted effects.

        • MajorHavoc@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          6 months ago

          Yeah. Injection has a place in test patterns. Thankfully, it’s usually possible to hide injection from strongly affecting anything else that matters, as long as the team hates injection deeply enough.

      • MajorHavoc@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        6 months ago

        Could be. There’s easier ways to minimize instances in memory. That’s what GLOBAL variables are for.

        P.S. I have now gone: 0 days without trying to wind up other senior developers.

    • xmunk@sh.itjust.works
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      6 months ago

      As a fellow PHP dev (working in laminas specifically) DI actually is fucking awful, there’s a distinction between a service factory pattern and this thing called DI which is similar to a service factory pattern but uses reflection based type sniffing to guess at which service you want where. I’d considered making a reference to it but PHP developers are few and far between these days.