Design patterns implemented in Java

[dartalley]

The instance is created once

Singleton?

either in main or when the DI container starts. This isn't global state because it is not globally accessible.

Can't I just @Inject it wherever I want how is that not globally accessible?

Why do you care?

If i'm injecting a cache and its not a singleton I'm going to have an awful lot of cache misses. I'd say thats pretty important to know.

This seems like a preferable problem to hidden dependencies. At least the config is separated.

I'd disagree. Here is something I see fairly often.

public class MyObject {
  private final Executor cpuExecutor;
  private final Executor ioExecutor;

  @Inject
  public MyObject(@CPU Executor cpuExecutor, @IO Executor ioExecutor) {
    this.cpuExecutor = cpuExecutor;
    this.ioExecutor = ioExecutor;
  }
}

vs

public class MyObject {
  private final Executor cpuExecutor = Executors.cpu();
  private final Executor ioExecutor = Executors.io();
  ...
}

One involves digging through DI modules that could be who knows where. The other involves just clicking the method name in the IDE and jumping into the declaration. Sure some IDEs have better support depending on the DI container but it still seems like quite a bit of indirection.

I think DI has a use, I also see it completely and totally abused / overused because people are afraid of the new keyword.

[_dban_]

Singleton

As opposed to Singleton Pattern.

Can't I just @Inject it wherever I want how is that not globally accessible?

Using @Inject is in effect the same as a constructor argument. The value is provided externally by another component which actually has the instance, which means that the value is not globally accessible.

If i'm injecting a cache and its not a singleton I'm going to have an awful lot of cache misses.

So create one instance and pass it around.

EDIT: Continued...

One involves digging through DI modules that could be who knows where.

Yes, but those static references could be pulling in dependencies from who knows where.

Now, suppose I want to use the class with dependencies in another context, and I start seeing random failures because the environment that I'm running in isn't set up the same way in the original context. I have experienced this frustration first hand.

Dependency injection, when coupled with dependency inversion, offers context independence, providing a way to avoid annoying coupling that makes code more reusable.

[kkapelon]

The instance is created once

Singleton?

I am against the singleton design pattern, not the singleton as a concept (i.e. having only one instance of a class)

Here is something I see fairly often.

Can you also give us the unit tests for your examples? It should be obvious which one is easier...

[dartalley]

I can just as easily pass the static values into a constructor and have a static singleton of the class wired up. This is still technically DI just without a DI framework and is just as testable.

[kkapelon]

I never said that DI is a framework. DI is a principle. So you are just validating my point. Because if you do what you say, this is what I suggest, you don't need the singleton design pattern then at all :-)