5 ms·

10 years ago, in my list of "Nice things to learn and do to be serious about software engineering", Design Patterns was probably in the top 3. Nowadays, it does

10 years ago, in my list of "Nice things to learn and do to be serious about software engineering", Design Patterns was probably in the top 3. Nowadays, it doesn't even make it to the top 20. I can't really say why, though. I guess 10 years ago I was really junior and I didn't know tons of stuff... It's not that nowadays I know all the patterns, but it's just that the noun "design pattern" already evokes in me red flags.

tabtab 5y ago
A lot of times partially good ideas get overblown and create "fad shrapnel" where they explode on the scene and get overused and overhyped by the naïve, Resume Oriented Programmers[1], or book/article pushers. One of the most frustrating things about Design Patterns is that it's never been clear when to use them and when not to. Making a good choice often requires intimately knowing the domain, and guessing the future well. Most us are lousy at predicting the future. If we were any good at it, we'd be golfing with Warren Buffett instead of figuring out why our Java won't compile on a Monday. Their Visitor Pattern scenario is crying out for a database, by the way. Don't reinvent a database in app code: you get spaghetti objects. Apply YAGNI and KISS, and only add design patterns if there is a clear and present need. [1] Buzzword collectors looking for their next gig and (mis) using your business as their personal college or R&D lab.
- galaxyLogic 5y ago
  > only add design patterns if there is a clear and present need. I know what you mean, don't copy the designs explained in design patterns books unless it makes sense. But to be clear on the wording, you don't really "add design patterns" ever. Your code is your design, designed by you. If there are recurring "patterns" in your code-solutions and recurring in the sense that others use them too and have documented them, then you can "see patterns" in your code. In other words you can recognize some patterns, some recurring structures in your code. Design Patterns are abstract entities you can not move them around. You can only describe them. Therefore people have tried to write books about them. You can only add code to your source-files, not "patterns". Can you see recurring patterns in your code? Maybe. If you think those recurring patterns are good enough to communicate to others then you may want to write a book or even just an email or HN post about them. The problem I see with the existing design patterns books is that a pattern describes a great solution in a specific context. But contexts vary wildly. Part of the context is the programming language used. They too vary wildly. So I think the basic idea of Design Patterns is great, but in practice their benefit may be limited depending on the generality/applicability and quality of the patterns described, in them books.
- Aeolun 5y ago
  > Their Visitor Pattern scenario is crying out for a database How so? Where you store your data doesn’t matter to your export logic. Whether it retrieves the original data structure from memory or the database doesn’t make a difference to the visitor.
TacticalCoder 5y ago
On the other hand they're really old now and, obviously, don't get that that old. So it's the kind of thing you learn once and then you'll inevitably find the use for some of them, or find them in codebases, for a very long time. I don't know if I to smile or lament that it's basically the ones that were explained in the gang of four's Design Patterns book... Nearly, what, 30 years ago now? (now I feel really old)
feanaro 5y ago
I think a partial cause for the loss of importance is due to design patterns being relatively oriented towards OOP. With the move away from OOP and towards functional programming and type theory, the term fell away because the design patterns relevant in those domains are not really called "design patterns".
- slaymaker1907 5y ago
  Functional programming still has patterns, they are just different patterns. For example, (let loop ([arg _]) ...) in Scheme for iteration. Monads are another one. Another common one is a foreach method/function for iteration over data instead of using iterators.
  - akavi 5y ago
    > Monads Are "just" an interface a data type can implement/obey (in languages that support higher kinded interfaces) > a foreach method/function for iteration over data Again, "just" an interface a data type can implement/obey.
    - deleted 5y ago
      [deleted]
    - jcelerier 5y ago
      Patterns being reified as language objects don't make them not-patterns. Trusty old function calls are still patterns, only reified from asm routines and procedures.
  - Aeolun 5y ago
    Something at the level of a loop does not strike me as something you can call a design pattern.
    - lotophage 5y ago
      I agree. I'd be more inclined to call something like that an idiom.
tester756 5y ago
>It's not that nowadays I know all the patterns, but it's just that the noun "design pattern" already evokes in me red flags. Me too, but if you think about it for a while, then design pattern is just name for some approaches to some problems that should improve communication by making it more precise.
doliveira 5y ago
Yeah, you can go too far, but I think it's a mistake to dismiss it like that. If you are a true senior, they probably sound as simple as breathing. But I've seen projects take up months instead of days simply for them not applying some knowledge of design patterns.

tabtab 5y ago

A lot of times partially good ideas get overblown and create "fad shrapnel" where they explode on the scene and get overused and overhyped by the naïve, Resume Oriented Programmers[1], or book/article pushers. One of the most frustrating things about Design Patterns is that it's never been clear when to use them and when not to. Making a good choice often requires intimately knowing the domain, and guessing the future well. Most us are lousy at predicting the future. If we were any good at it, we'd be golfing with Warren Buffett instead of figuring out why our Java won't compile on a Monday. Their Visitor Pattern scenario is crying out for a database, by the way. Don't reinvent a database in app code: you get spaghetti objects. Apply YAGNI and KISS, and only add design patterns if there is a clear and present need. [1] Buzzword collectors looking for their next gig and (mis) using your business as their personal college or R&D lab.

galaxyLogic 5y ago
> only add design patterns if there is a clear and present need. I know what you mean, don't copy the designs explained in design patterns books unless it makes sense. But to be clear on the wording, you don't really "add design patterns" ever. Your code is your design, designed by you. If there are recurring "patterns" in your code-solutions and recurring in the sense that others use them too and have documented them, then you can "see patterns" in your code. In other words you can recognize some patterns, some recurring structures in your code. Design Patterns are abstract entities you can not move them around. You can only describe them. Therefore people have tried to write books about them. You can only add code to your source-files, not "patterns". Can you see recurring patterns in your code? Maybe. If you think those recurring patterns are good enough to communicate to others then you may want to write a book or even just an email or HN post about them. The problem I see with the existing design patterns books is that a pattern describes a great solution in a specific context. But contexts vary wildly. Part of the context is the programming language used. They too vary wildly. So I think the basic idea of Design Patterns is great, but in practice their benefit may be limited depending on the generality/applicability and quality of the patterns described, in them books.
Aeolun 5y ago
> Their Visitor Pattern scenario is crying out for a database How so? Where you store your data doesn’t matter to your export logic. Whether it retrieves the original data structure from memory or the database doesn’t make a difference to the visitor.

TacticalCoder 5y ago

On the other hand they're really old now and, obviously, don't get that that old. So it's the kind of thing you learn once and then you'll inevitably find the use for some of them, or find them in codebases, for a very long time. I don't know if I to smile or lament that it's basically the ones that were explained in the gang of four's Design Patterns book... Nearly, what, 30 years ago now? (now I feel really old)

feanaro 5y ago

I think a partial cause for the loss of importance is due to design patterns being relatively oriented towards OOP. With the move away from OOP and towards functional programming and type theory, the term fell away because the design patterns relevant in those domains are not really called "design patterns".

slaymaker1907 5y ago
Functional programming still has patterns, they are just different patterns. For example, (let loop ([arg _]) ...) in Scheme for iteration. Monads are another one. Another common one is a foreach method/function for iteration over data instead of using iterators.
- akavi 5y ago
  > Monads Are "just" an interface a data type can implement/obey (in languages that support higher kinded interfaces) > a foreach method/function for iteration over data Again, "just" an interface a data type can implement/obey.
  - deleted 5y ago
    [deleted]
  - jcelerier 5y ago
    Patterns being reified as language objects don't make them not-patterns. Trusty old function calls are still patterns, only reified from asm routines and procedures.
- Aeolun 5y ago
  Something at the level of a loop does not strike me as something you can call a design pattern.
  - lotophage 5y ago
    I agree. I'd be more inclined to call something like that an idiom.

tester756 5y ago

>It's not that nowadays I know all the patterns, but it's just that the noun "design pattern" already evokes in me red flags. Me too, but if you think about it for a while, then design pattern is just name for some approaches to some problems that should improve communication by making it more precise.

doliveira 5y ago

Yeah, you can go too far, but I think it's a mistake to dismiss it like that. If you are a true senior, they probably sound as simple as breathing. But I've seen projects take up months instead of days simply for them not applying some knowledge of design patterns.