3 ms·
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 overcom
by lsd5you 17y ago
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.
- andreyf 17y agoWhat 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.
- mhansen 17y agoThen you aren't gaining anything over simply calling 'new' on that class, negating the point of the factory pattern, right?
- orangecat 17y agoThe 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.
- lucifer 17y agoJava 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(); }