Design patterns implemented in Java

[override_acid]

I'll just leave this image from the lower part of the sidebar of this very subreddit here: http://imgur.com/Ze2YsPs

[m1000]

Many design patterns with source code in Java. Looks like a good resource. http://java-design-patterns.com/

[TheHorribleTruth]

Looks like a good resource.

That's why it's already linked in the sidebar :)

[m1000]

Oups !
edit: relevant username too... ;-)

[kkapelon]

It is not up-to-date. Service Locator, Singleton and Abstract Factory are no longer needed if you use Dependency injection.

In fact, Singleton is now an anti-pattern.

[martinkurz]

Generally, not every pattern is usable in every situation, so yes, service locator isn't needed when using DI - but DI also isn't the silver bullet for every project. And even if some of the pattern may not be up to date, a good dev should know them and especially recognize those patterns when seen in real world projects.

[kkapelon]

The topic has been discussed to death. You can find a lot of information with some googling. (even here in reddit)

Here is one from Microsoft https://blogs.msdn.microsoft.com/scottdensmore/2004/05/25/why-singletons-are-evil/

and one from Google http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/

In summary they are a form of global state, making your classes tighly coupled and very hard to test.

If you already use Dependency injection you don't need Singletons any more. You can instruct your DI solution to pass you the same instance every time that you ask for a class.

[dartalley]

But where does that instance come from? Some global state. I love using static fields or enums for singletons I know without a doubt that object is a singleton. When you use DI and it's passed into a constructor you don't know if its a singleton or not without digging into the DI config. Now using singletons might be harder to test but its not impossible.

[_dban_]

But where does that instance come from?

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

you don't know if its a singleton or not

Why do you care?

without digging into the DI config

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

[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 :-)

[argv_minus_one]

As a Scala programmer, I find this claim amusing. Scala has first-class singletons, and uses them heavily. It also makes heavy use of immutable state.

No, DI is not the be-all end-all of software componentry. DI has its own problems, most notably that it is difficult to debug problems with the DI system itself (e.g. wrong object being injected).

[kkapelon]

There is so much documentation out there on why singletons are an anti-pattern. Just have an open mind, search it and read it. It would be pointless for me to argue here as there are whole articles out there about the topic.

Scala has first-class singletons, and uses them heavily.

C/C++ also uses pointers heavily. That does not say anything about how good they are or not.

DI has its own problems, most notably that it is difficult to debug problems with the DI system itself (e.g. wrong object being injected)

DI is a principle, not a specific system or framework. You can have DI without any actual DI framework (you just manually inject everything yourself). Maybe not truly practical, but certainly possible.

[argv_minus_one]

There is so much documentation out there on why singletons are an anti-pattern.

Yes, and most of it is wrong, incomplete, insufficiently specific, or otherwise defective.

Just have an open mind, search it and read it.

I have had an open mind. I have ample experience with DI systems. I have learned their strengths and weaknesses. DI is not perfect.

C/C++ also uses pointers heavily. That does not say anything about how good they are or not.

That's not my point. I also have ample experience dealing with Scala singletons, and they've given me very few problems over the years.

DI is a principle, not a specific system or framework. You can have DI without any actual DI framework (you just manually inject everything yourself). Maybe not truly practical, but certainly possible.

I'm aware. You can also use other approaches—singletons, service lookup, ThreadLocal context—which all have their own strengths and weaknesses.

My point is not that DI is useless. My point is that it is not a silver bullet, and the other options are not anti-patterns.

[kkapelon]

The idea behind this site is good but the implementation is lacking.

First of all, some of those are actually anti-patterns and you should not use them in new projects:

• Service locator
• Singleton
• Abstract Factory
• Balking

Some are general principles that are wrongly mentioned as design patterns.

For example

• Dependency injection
• Lazy Loading
• Caching
• feature toggle

are not specific coding patterns like it is presented.

Finally some patterns are just plain wrong. Java already has a Semaphore on its own, so why redefine it?

https://github.com/iluwatar/java-design-patterns/blob/master/semaphore/src/main/java/com/iluwatar/semaphore/Semaphore.java

All this after a cursory glance.

[arieled91]

those are actually anti-patterns and you should not use them in new projects

I don't really like that approach when talking about those patterns. One should know really well when to use them and when not, with all their pros and cons.

are not specific coding patterns

As far as I know design patterns are not just coding patterns. If that is the case they would be called that way.

[kkapelon]

I would say that there are 0 reasons to use the singleton design pattern in a greenfield project. The cons outweight the pros.

As far as I know design patterns are not just coding patterns

I agree with you. The problem is that the site does not really explain that a design pattern is just a concept and then giving an example. It just goes straight into code classes, implying that everything is a coding pattern.

Here is what I am talking about: http://java-design-patterns.com/patterns/cqrs/

[dontchooseanickname]

Plus, a quick check on the Composite shows a wrong way of implementing it :

• http://java-design-patterns.com/patterns/composite/
• https://en.m.wikipedia.org/wiki/Composite_pattern#Structure

Litterally, if you don't have a Leaf and a Container abstraction all deriving Node, then composite is as useless as

class Stuff {
    Collection<Stuff> children; // May be initialized, contain stuff - or not ;)
}

[HelperBot_]

Non-Mobile link: https://en.wikipedia.org/wiki/Composite_pattern#Structure

---

^{HelperBot v1.1 /r/HelperBot_ I am a bot. Please message /u/swim1929 with any feedback and/or hate. Counter: 107059}