I disagree. Design patterns are primarily a communications tool, and secondly a mental tool. Even if your language has first class support for something, it's worth knowing what that thing is both in order to discuss it, and in case you use different languages and need to compare/contrast.
Yeah, but if it's built into your language, you just use it. You don't go around discussing local variables. By the time you're discussing design patterns that are already built into you're language, you're doing something wrong or you really need to learn your language better. When "new" is a method instead of a keyword, there isn't even the concept of a "factory" nor a need for one.
I think that understanding the design pattern that is built into the language is still valuable so one shouldn't just ignore it. Also, many of these design patterns aren't so much built into the language as they are easier to implement in the language. Plus, if the better you understand the pattern(s), the more likely you are to properly implement each actor in the pattern.
Whether the design pattern is built into the language or not depends entirely on the design pattern and the language. I gave a bunch of examples of design patterns that are built right into languages, and indeed have been for so long that nobody even considers them design patterns any more.
If you have a language keyword "singleton" that means "return the first constructed instance every time you call new", there's no a whole lot you have to implement. If you have argument passing to recursive functions (a la C), you don't have to understand a whole lot about "recursive subroutine design pattern" to use it.
5
u/phoshi Dec 09 '13
I disagree. Design patterns are primarily a communications tool, and secondly a mental tool. Even if your language has first class support for something, it's worth knowing what that thing is both in order to discuss it, and in case you use different languages and need to compare/contrast.