4 ms·

Are Design Patterns really so out of fashion with the youth of today that nobody here mentions Design Patterns as their answer? Because it is mine, for better

Are Design Patterns really so out of fashion with the youth of today that nobody here mentions Design Patterns as their answer? Because it is mine, for better or worse. It took me from understanding OO to understanding how to build large systems with OO, writing maintainable code and using proper encapsulation. A much deeper work than Code Complete (though the latter is worth reading too). I have used functional languages as well (ML, Lisp; not Haskell yet though I think I get what monads are; plus I write a lot of Python, C++, JS in functional style) but I have yet to use them for any project as big. I hope I get the chance to one day. But for now Design Patterns gets my vote.

gnaritas 9y ago
> Are Design Patterns really so out of fashion with the youth of today that nobody here mentions Design Patterns as their answer? Apparently so; sad.
- deleted 9y ago
  [deleted]
jdmichal 9y ago
I don't think design patterns went out of fashion. I think the opposite happened -- they gained such mindshare that they became a solution looking for a problem for many people. That is, they forgot that design patterns are meant to solve problems, and that you should also only solve problems that actually exist. Instead we started getting things that resembled "Hello World Enterprise Edition" [0], which has been dubbed "lasagna code" -- lots of layers with a little bit of filling in each one. [0] https://gist.github.com/lolzballs/2152bc0f31ee0286b722 https://gist.github.com/lolzballs/2152bc0f31ee0286b722
- usmannk 9y ago
  They meant the book Design Patterns https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...
  - jdmichal 9y ago
    The person I replied to, sideshowb, explicitly asked about both design patterns and Design Patterns. Regardless, that book was what elevated design patterns into common knowledge within the object-oriented world. Their fate is tied together; the book and the patterns described within are practically synonymous.
btilly 9y ago
I'm nearing 50 so I'm hardly a youth. http://www.perlmonks.org/?node_id=133399 http://www.perlmonks.org/?node_id=133399 does a very good job of explaining why Design Patterns is a book to be careful with. By contrast Code Complete won't steer people wrong. See https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo... for a cautionary tale about how a pursuit of OO purity can result in great verbosity, hiding intent behind a barrage of patterns. Resulting in code that I, for one, would rather not work with.
- sideshowb 9y ago
  Agree on both those fronts, if you're not careful. Still dp influenced my coding more than any other book to date, which was the original question.
  - btilly 9y ago
    As to that, Design Patterns did not influence my coding style very much. By contrast Code Complete was the first book that I read about how to structure code, and I've gained more from it on multiple rereads. I consider it a much better book. But then again I'm hardly enthusiastic about OO. See http://www.perlmonks.org/?node_id=318257 http://www.perlmonks.org/?node_id=318257 for more on my perspective.
- sideshowb 9y ago
  That second link is great btw. I've always felt that aspect of java was odd, and I do like modern fables :-)
- gnaritas 9y ago
  Yegge critiquing OO for verbosity, that's a hoot; talk about the pot calling the kettle black.
  - btilly 9y ago
    But only a person as verbose as Yegge can really on about Java at sufficient length to do the topic justice.
hyperpallium 9y ago
> build large systems DP are oft misused, but I think the main idea is a pattern language - a way to communicate to other developers what the architecture is. This is especially important on larger, more complex projects with more developers and developer turnover. Understanding the architecture of a project is crucial for grokking it, but usually not well documented. Even just "DPs are naming conventions" is helpful in this regard. I really disagree with the idea that most DPs are particularly clever or helpful - they are just the way you'd end up solving those kinds of problems yourself. If you look at your own pre-DP code, you'll see design patterns. What they give is a standardized terminology ("pattern language"). Sometimes an architecture seems more complex than necessary, but makes sense as you better understand the whole problem. e.g. how curl handles http. e.g. youtube-dl. (for me, when I reverse-engineered mini-versions of them, then studied their source) tl;dr "DPs are docs"
- tonyedgecombe 9y ago
  I've heard a lot of people saying they were already using these patterns before they read the gang of four book, it just put a label on those patterns for them.
mattmanser 9y ago
I think there are two reasons Design Patterns have disappeared: 1. Being able to use functional programming concepts in OO languages made a lot of design patterns irrelevant (Python, Ruby, C# 3.5, C++11, Java 8). I feel Crockford's The Good Parts really introduced these concepts to the OO crowd with javascript acting as the bridging language for the concepts. 2. Many design patterns were terrible ideas in practice. Factory patterns were a disaster, as were many of the others. Good in theory, utterly useless in practice. There was a blog here recently about TDD that argued TDD is useless because you need to be a great architect to do TDD correctly, and most programmers aren't great architects. Design patterns had the same problem, it was very easy to get them wrong and create an utter mess. Ultimately it's more maintainable to have a complicated monolith method than some crazy pattern no-one understands or dare touch.

gnaritas 9y ago

> Are Design Patterns really so out of fashion with the youth of today that nobody here mentions Design Patterns as their answer? Apparently so; sad.

deleted 9y ago
[deleted]

jdmichal 9y ago

I don't think design patterns went out of fashion. I think the opposite happened -- they gained such mindshare that they became a solution looking for a problem for many people. That is, they forgot that design patterns are meant to solve problems, and that you should also only solve problems that actually exist. Instead we started getting things that resembled "Hello World Enterprise Edition" [0], which has been dubbed "lasagna code" -- lots of layers with a little bit of filling in each one. [0] https://gist.github.com/lolzballs/2152bc0f31ee0286b722 https://gist.github.com/lolzballs/2152bc0f31ee0286b722

usmannk 9y ago
They meant the book Design Patterns https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...
- jdmichal 9y ago
  The person I replied to, sideshowb, explicitly asked about both design patterns and Design Patterns. Regardless, that book was what elevated design patterns into common knowledge within the object-oriented world. Their fate is tied together; the book and the patterns described within are practically synonymous.

btilly 9y ago

I'm nearing 50 so I'm hardly a youth. http://www.perlmonks.org/?node_id=133399 http://www.perlmonks.org/?node_id=133399 does a very good job of explaining why Design Patterns is a book to be careful with. By contrast Code Complete won't steer people wrong. See https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo... for a cautionary tale about how a pursuit of OO purity can result in great verbosity, hiding intent behind a barrage of patterns. Resulting in code that I, for one, would rather not work with.

sideshowb 9y ago
Agree on both those fronts, if you're not careful. Still dp influenced my coding more than any other book to date, which was the original question.
- btilly 9y ago
  As to that, Design Patterns did not influence my coding style very much. By contrast Code Complete was the first book that I read about how to structure code, and I've gained more from it on multiple rereads. I consider it a much better book. But then again I'm hardly enthusiastic about OO. See http://www.perlmonks.org/?node_id=318257 http://www.perlmonks.org/?node_id=318257 for more on my perspective.
sideshowb 9y ago
That second link is great btw. I've always felt that aspect of java was odd, and I do like modern fables :-)
gnaritas 9y ago
Yegge critiquing OO for verbosity, that's a hoot; talk about the pot calling the kettle black.
- btilly 9y ago
  But only a person as verbose as Yegge can really on about Java at sufficient length to do the topic justice.

hyperpallium 9y ago

> build large systems DP are oft misused, but I think the main idea is a pattern language - a way to communicate to other developers what the architecture is. This is especially important on larger, more complex projects with more developers and developer turnover. Understanding the architecture of a project is crucial for grokking it, but usually not well documented. Even just "DPs are naming conventions" is helpful in this regard. I really disagree with the idea that most DPs are particularly clever or helpful - they are just the way you'd end up solving those kinds of problems yourself. If you look at your own pre-DP code, you'll see design patterns. What they give is a standardized terminology ("pattern language"). Sometimes an architecture seems more complex than necessary, but makes sense as you better understand the whole problem. e.g. how curl handles http. e.g. youtube-dl. (for me, when I reverse-engineered mini-versions of them, then studied their source) tl;dr "DPs are docs"

tonyedgecombe 9y ago
I've heard a lot of people saying they were already using these patterns before they read the gang of four book, it just put a label on those patterns for them.

mattmanser 9y ago

I think there are two reasons Design Patterns have disappeared: 1. Being able to use functional programming concepts in OO languages made a lot of design patterns irrelevant (Python, Ruby, C# 3.5, C++11, Java 8). I feel Crockford's The Good Parts really introduced these concepts to the OO crowd with javascript acting as the bridging language for the concepts. 2. Many design patterns were terrible ideas in practice. Factory patterns were a disaster, as were many of the others. Good in theory, utterly useless in practice. There was a blog here recently about TDD that argued TDD is useless because you need to be a great architect to do TDD correctly, and most programmers aren't great architects. Design patterns had the same problem, it was very easy to get them wrong and create an utter mess. Ultimately it's more maintainable to have a complicated monolith method than some crazy pattern no-one understands or dare touch.