> When design patterns came along, Java folks talked about them as though they
were a wonderful new invention. But they only exist because Java is so
clumsy that it needed crutches to do things that had been easy and natural
in other languages for years; someone merely came along and gave the
crutches names.
Design patterns are a useful way of thinking about any sort of design, not
even just in programming. Novels and paintings have them, too, so does your
favourite language. There will always emerge from experience particular ways
of using your medium, and having names for those patterns can actually be
pretty useful for thinking about them and structuring them into a good design
(like how SICP talks about knowing a spirit's name gives you power over it).
You can't avoid using design patterns; someone just might not have come
along and named them yet, or you might not be aware of them.
The GoF book itself actually discusses this in the first chapter a bit, here's
a relevant part:
Point of view affects one's interpretation of what is and isn't a pattern. One
person's pattern can be another person's primitive building block. For this
book we have concentrated on patterns at a certain level of abstraction. [...]
Our patterns assume Smalltalk/C++-level language features, and that choice
determines what can and cannot be implemented easily. If we assumed procedural
languages, we might have included design patterns called "Inheritance,"
"Encapsulation," and "Polymorphism." Similarly, some of our patterns are
supported directly by the less common object-oriented languages. CLOS has
multi-methods, for example, which lessen the need for a pattern such as
Visitor.
Design patterns are a useful way of thinking about any sort of design, not even just in programming. Novels and paintings have them, too, so does your favourite language. There will always emerge from experience particular ways of using your medium, and having names for those patterns can actually be pretty useful for thinking about them and structuring them into a good design (like how SICP talks about knowing a spirit's name gives you power over it). You can't avoid using design patterns; someone just might not have come along and named them yet, or you might not be aware of them.
The GoF book itself actually discusses this in the first chapter a bit, here's a relevant part:
Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern can be another person's primitive building block. For this book we have concentrated on patterns at a certain level of abstraction. [...] Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance," "Encapsulation," and "Polymorphism." Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor.