3 ms·

Did patterns really fail? Or did we just out grow them? For me personally patterns have always been valuable as a means of communication. Before patterns one t

by pan69 8y ago

Did patterns really fail? Or did we just out grow them? For me personally patterns have always been valuable as a means of communication. Before patterns one team would talk about "device for when at rest" and another team would talk about "timber and fabric object for relax position". Now we just call it "chair" and it's common. Just like, singleton, command, proxy, whatever. Maybe design patterns simply have done their job.

tonyedgecombe 8y ago
Yes, several people I have spoken to said the main thing they got from the GoF book was giving a name to things they were already doing.
- danielbarla 8y ago
  I always felt that this is a larger value than the implementation details. The software industry was / is still in need of more standardization and common vocabulary.
- gmueckl 8y ago
  The other way to use GoF and related texts is as an inspiration. It's been a while since the last difficult software design problem that I had to solve. But I reread GoF to get a new perspective on what I was trying to solve. Also, I found that some people tend to take the descriptions of design patterns as a kind of gospel and any deviation from the Right Path outlined therein is heresy. But that's how the application of design patterns leads to failure. These are raw building materials for your design. You always have to shape them to fit your exact needs. Extend them, reduce them, cut them in half and glue the halves back together with their backsides - do what you must to get a clever design that leads to simple code.
  - Terr_ 8y ago
    > I found that some people tend to take the descriptions of design patterns as a kind of gospel and any deviation from the Right Path outlined therein is heresy. I think the key aspect which distinguishes "dogmatism" from "reasonable" is whether the choice they're concerned with would cause a communication-error or leaky-abstraction.
BerislavLopac 8y ago
Yes, creating common terminology is important, and the fact that we're still doing it for basic things simply shows that this field is still in its infancy. As we all know, naming things is hard, and in many cases it was less than fortunate. E.g. I'm really excited by the concepts of "event sourcing" and "CQRS", but think that those names are quite unfortunate choices. On the other hand we have "singleton", which might not be to everyone's liking as a concept, but I think we can all agree that the name is quite clear and descriptive (that said, I've always been sorry that we didn't go for the alternative choice, "highlander").

by pan69 8y ago

tonyedgecombe 8y ago

Yes, several people I have spoken to said the main thing they got from the GoF book was giving a name to things they were already doing.

danielbarla 8y ago
I always felt that this is a larger value than the implementation details. The software industry was / is still in need of more standardization and common vocabulary.
gmueckl 8y ago
The other way to use GoF and related texts is as an inspiration. It's been a while since the last difficult software design problem that I had to solve. But I reread GoF to get a new perspective on what I was trying to solve. Also, I found that some people tend to take the descriptions of design patterns as a kind of gospel and any deviation from the Right Path outlined therein is heresy. But that's how the application of design patterns leads to failure. These are raw building materials for your design. You always have to shape them to fit your exact needs. Extend them, reduce them, cut them in half and glue the halves back together with their backsides - do what you must to get a clever design that leads to simple code.
- Terr_ 8y ago
  > I found that some people tend to take the descriptions of design patterns as a kind of gospel and any deviation from the Right Path outlined therein is heresy. I think the key aspect which distinguishes "dogmatism" from "reasonable" is whether the choice they're concerned with would cause a communication-error or leaky-abstraction.

BerislavLopac 8y ago

Yes, creating common terminology is important, and the fact that we're still doing it for basic things simply shows that this field is still in its infancy. As we all know, naming things is hard, and in many cases it was less than fortunate. E.g. I'm really excited by the concepts of "event sourcing" and "CQRS", but think that those names are quite unfortunate choices. On the other hand we have "singleton", which might not be to everyone's liking as a concept, but I think we can all agree that the name is quite clear and descriptive (that said, I've always been sorry that we didn't go for the alternative choice, "highlander").