3 ms·
The author claims that if a language has features that allow patterns to be automated, there will still be patterns. Perhaps that's true, but the logic seems to
by Darmani 18y ago
The author claims that if a language has features that allow patterns to be automated, there will still be patterns. Perhaps that's true, but the logic seems to be that more-than-necessary code-duplication is acceptable because eliminating 100% of code duplication is impossible -- certainly not a hacker's worldview. That Ruby needs to explicitly bind a variable to the result of an expression in an if statement due to lack of ability to implement effective anaphora does not excuse Java's need to manually implement what in Ruby is just "include Singleton".
(Whenever a post comes up defending Design Patterns, it's also obligatory that someone pull out this link: http://blog.plover.com/prog/design-patterns.html http://blog.plover.com/prog/design-patterns.html .)
- gruseom 18y agoThe post you link to is worth reading. I hadn't seen it before, so thanks for obligatorily pulling it out :)
- DougBTX 18y agoYou can't do "include Singleton" until you've identified the "Singleton" pattern. The author says that identifying high level patterns is a) the point of the book (for OO languages), and b) that identifying patterns is a good thing. The author is perfectly right to say that interpreting a book which catalogues patterns in existing software as a prescription for how to implement new software is a great misunderstanding, as you've demonstrated in the post above.