4 ms·

Exactly. You can follow SRP, use clean constructors and do it by hand. An IoC container is a nice /mechanical/ helper to do the wire up for you. I really disli

by ecoffey 12y ago

Exactly. You can follow SRP, use clean constructors and do it by hand. An IoC container is a nice /mechanical/ helper to do the wire up for you. I really dislike that the majority (all?) of the javaland IoC containers work with annotations; I believe that your object graphs should have no idea if they were built "by hand" with manual calls to new, or resolved from a container.

pbh101 12y ago
I haven't used it yet but I'm excited by the possibility of dagger 2, which generates the code that constitutes the dependency graph upon compile. http://google.github.io/dagger/ http://google.github.io/dagger/
emsy 12y ago
Uncle Bob imho has a pretty good strategy for this problem: https://twitter.com/unclebobmartin/status/308983161143058432 https://twitter.com/unclebobmartin/status/308983161143058432
- UK-AL 12y ago
  He basically just described what a container does. You put objects in the container in main, then it resolves everything else.
  - emsy 12y ago
    That's exactly what it's not. A container is a dependency in itself. Secondly, the wiring of the dependencies happens in one place in the code, not littered in the codebase or a proprietary obstruct XML file. And lastly, a loose container tends to be abused. When a dependency can be included with a simple annotation, everything depends on everything.
    - UK-AL 12y ago
      Errr, you setup up the container in one place, normally main or somewhere at the start. Very few containers are xml only these days. There's normally section at the start like container.RegisterType<IMessageQueue, MSMQMessageQueue> container.RegisterType<IGeocoder, GoogleGeocoder> Modern containers don't even use annotations, they just scan the constructor parameters.
      - moomin 12y ago
        Yes, but they still magically figure out what goes into what. In the case that you've got a relatively flat structure (services injecting into lots of handlers) this is convenient. When you're building a complex tree, it reduces your understanding of the structure of your code.
viggity 12y ago
didn't realize that about javaland. almost all the projects I've worked on in .net use conventions to wire interfaces to concrete types. the IoC is mentioned in one file that defines the conventions and the 2-3 odd-ball one-offs. I've been on one project that manually wired everything, it was crazy. such a waste of time.

by ecoffey 12y ago

pbh101 12y ago

I haven't used it yet but I'm excited by the possibility of dagger 2, which generates the code that constitutes the dependency graph upon compile. http://google.github.io/dagger/ http://google.github.io/dagger/

emsy 12y ago

Uncle Bob imho has a pretty good strategy for this problem: https://twitter.com/unclebobmartin/status/308983161143058432 https://twitter.com/unclebobmartin/status/308983161143058432

UK-AL 12y ago
He basically just described what a container does. You put objects in the container in main, then it resolves everything else.
- emsy 12y ago
  That's exactly what it's not. A container is a dependency in itself. Secondly, the wiring of the dependencies happens in one place in the code, not littered in the codebase or a proprietary obstruct XML file. And lastly, a loose container tends to be abused. When a dependency can be included with a simple annotation, everything depends on everything.
  - UK-AL 12y ago
    Errr, you setup up the container in one place, normally main or somewhere at the start. Very few containers are xml only these days. There's normally section at the start like container.RegisterType<IMessageQueue, MSMQMessageQueue> container.RegisterType<IGeocoder, GoogleGeocoder> Modern containers don't even use annotations, they just scan the constructor parameters.
    - moomin 12y ago
      Yes, but they still magically figure out what goes into what. In the case that you've got a relatively flat structure (services injecting into lots of handlers) this is convenient. When you're building a complex tree, it reduces your understanding of the structure of your code.

viggity 12y ago

didn't realize that about javaland. almost all the projects I've worked on in .net use conventions to wire interfaces to concrete types. the IoC is mentioned in one file that defines the conventions and the 2-3 odd-ball one-offs. I've been on one project that manually wired everything, it was crazy. such a waste of time.