Hacker News new | comments | show | ask | jobs | submit login

He could make a stronger case, by posting an example. Even then he would be trying to prove a negative - i.e. that there is no design pattern that isn't overcoming a language flaw.

What about the much maligned factory pattern. It boils down to a method that provides an implementation, and can be considered (when not misused) a single point of configuration in an application. (e.g. switch the factory to use html instead of pdf).

My view was always that people could learn patterns much the same way that they can learn a 2nd language. That is end up with a high level of knowledge about the grammar/patterns but not be able to use them fluently.

What about the much maligned factory pattern

If classes are first-class variables (as in Python, and now even Java (I think)), this is replaced with a constructor which takes a class as an argument.

Then you aren't gaining anything over simply calling 'new' on that class, negating the point of the factory pattern, right?

The point of the factory pattern is that you don't always want a new instance, and you don't always want a specific type. "new Foo()" necessarily does both, while Foo.new() can potentially do neither.

Java has always had the ability to reference Class types, and, to instantiate instances of that type using a standard method:

Object makeOne (Class fooClass) { return fooClass.newInstance(); }

You are missing the point of a factory pattern, which is informed by the non-accidental pattern name: 'Factory'.

[edit: using generics it is even type safe]: <T> T makeOne (Class<T> clazz) { return clazz.newInstance(); }

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact