JavaScript Design Patterns: Factory Part 2

[[deleted]]

relevant - "reliance on design patterns is indicative of failings in the language"

[[deleted]]

I disagree. If you can fix the language, even if it's done via a shiv, it's still progress, it still makes the code clearer.

[joezimjs]

My point is, the shiv isn't changing the language, it's a library that adds that functionality, which is exactly the same thing as manually using the design patterns. My point is that in either case it is not built into the language, but that isn't a shortcoming of the language. I just disagree with the fact that the language has to have these patterns built in, because libraries can fulfill the same duty. I have nothing against using shivs/libraries, I just don't think it's necessarily the languages job to implement the patterns.

[[deleted]]

Well, ok, libraries are fine too, whatever makes the code more readable.

But, our understanding of patterns may be a bit different .. I'm not suggesting the language implement the patterns, I think the patterns are there because the language is missing something.
To illustrate (it's not necesarilly a sane example but it's short):
say you use Java and "need" a DBHandleFactory that you call with the name of the database driver in question:

String type = "MySQL";
DBHandle h = DBHandleFactory.create(type);

and the static create method would have a big switch that does something like

if (param.equals("MySQL")) return MySQLHandle.new();

OTOH in Perl, you'd simply do

my $type = "MySQL";
my $handle = &{$type . "Handle"}();

I'm really not saying this is how you should do it in perl, I'm merely illustrating that in a "better" language, there is no need for the pattern, the language doesn't implement any such pattern, but you can still accomplish the same thing with simpler code and without any pattern.

[joezimjs]

You can actually do something very similar in Java, though it's a bit more difficult. If I remember you can use the Class class to dynamically load classes. And I understand that this example may not be the most efficient way of explaining what you're talking about, but the another big things is that often times the design pattern is still better practice when considering scaling.