5 ms·

Skip design patterns, I think it locks developers into a sort of religious loyalty towards OOP abstractions. When you understand the pattern it describes you ge

Skip design patterns, I think it locks developers into a sort of religious loyalty towards OOP abstractions. When you understand the pattern it describes you get a sort of catharsis for discovering a new interesting thing. In reality, any of these patterns are just bad despite the cleverness. Modern programming is heading in a different direction already so it'd be better to move forward without it.

criddell 7y ago
I disagree because people often don't have the luxury of working on greenfield projects. When you are working with an old codebase, you are going to run across design patterns. You will see terms like factory, builder, observer, decorator, pool, flyweight, etc... and it's going to be helpful to know what those are. A lot of the value of design patterns was in the terminology.
- crimsonalucard 7y ago
  Times have changed where few non-greenfield projects use these patterns as well. Languages like Go and javascript will rarely have these patterns. I would avoid depending on the programming language. If you are working with Java or C++ these are the two languages where these patterns will appear, even in greenfield projects due to developer loyalty. If you are working with languages other than this, then you are more likely not to encounter these patterns that often. Thus avoid the book unless you want to become an expert in Java. Also these patterns can be learned without the GoF book just off of quick scans of articles on the internet.
  - james_s_tayler 7y ago
    What has replaced them? Presumably some of the problems they intend to solve still exist. Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z? I've seen some of those patterns leveraged to great effect in modern software. But genuinely curious about alternative ways to solve the same problems. I've definitely noticed the trend towards more and more functional programming these days. I doubt it's simply a case of "just use FP and there are no more problems".
    - crimsonalucard 7y ago
      This isn't about OOP vs. FP. This is about OOP vs. everything else. Rust, Go and javascript are three languages that are moving away from the OOP paradigm. None of those three languages are classified as functional. >Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z? No. A general trend is an anecdotal observation. Still a quick google search yielded: https://blog.cleancoder.com/uncle-bob/images/fpvsoo.jpg https://blog.cleancoder.com/uncle-bob/images/fpvsoo.jpg Take a look at the following video: https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=QM1iUe6IofM While I don't agree with a lot of it, I think it sums up my opinion really clearly. It's not about DP's but because DP's focus around OOP and the video is a criticism of OOP therefore the arguments apply to DPs.
      - james_s_tayler 7y ago
        Thanks. I've observed this as a general trend too. I'm starting to become more and more interested in the functional way of thinking. The image you linked it interesting. I want to dive more in on the how/specifics. I don't necessarily buy the argument it's trying to make that "just make a function and you no longer have a need for factory pattern". You're trying to accomplish something fairly specific with that. Functions compose, I could see how there are properties they have that can be leveraged to achieve the same goal, but I'm guessing the functions you write or the way you write functions to achieve each of those specific aims likely differ in subtle yet important ways. I'm very interested in those details.
        crimsonalucard 7y ago
        >I don't necessarily buy the argument it's trying to make that "just make a function and you no longer have a need for factory pattern". The same pattern is achievable with functions but the implementation is so trivial in FP that it doesn't even need a name: Just have a function return another function. That's a function factory. Same thing with dependency injection: Just have a function take another function as a parameter. Outside of this I wouldn't even recommend either pattern at all. It's bad practice in all paradigms. Only have data flow through your execution path, don't have new "execution paths" flowing through your execution paths, such architectures tend to be over-engineered.
hhjinks 7y ago
Thanks for the heads up. I'm going to read it soon despite your warnings, but I'll keep what you're saying in mind while going through it.
- ngruhn 7y ago
  I agree with crimsonalucard but for different reasons. This book is catalog. It's like reading a dictionary from start to finish. This becomes dull fast and you don't learn efficiently. Sure you can just use it to look a pattern up once in a while but then again you might as well read the Wikipedia article.
jamestimmins 7y ago
Could you summarize the different direction that you see things moving?
- crimsonalucard 7y ago
  Less OOP.

criddell 7y ago

I disagree because people often don't have the luxury of working on greenfield projects. When you are working with an old codebase, you are going to run across design patterns. You will see terms like factory, builder, observer, decorator, pool, flyweight, etc... and it's going to be helpful to know what those are. A lot of the value of design patterns was in the terminology.

crimsonalucard 7y ago
Times have changed where few non-greenfield projects use these patterns as well. Languages like Go and javascript will rarely have these patterns. I would avoid depending on the programming language. If you are working with Java or C++ these are the two languages where these patterns will appear, even in greenfield projects due to developer loyalty. If you are working with languages other than this, then you are more likely not to encounter these patterns that often. Thus avoid the book unless you want to become an expert in Java. Also these patterns can be learned without the GoF book just off of quick scans of articles on the internet.
- james_s_tayler 7y ago
  What has replaced them? Presumably some of the problems they intend to solve still exist. Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z? I've seen some of those patterns leveraged to great effect in modern software. But genuinely curious about alternative ways to solve the same problems. I've definitely noticed the trend towards more and more functional programming these days. I doubt it's simply a case of "just use FP and there are no more problems".
  - crimsonalucard 7y ago
    This isn't about OOP vs. FP. This is about OOP vs. everything else. Rust, Go and javascript are three languages that are moving away from the OOP paradigm. None of those three languages are classified as functional. >Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z? No. A general trend is an anecdotal observation. Still a quick google search yielded: https://blog.cleancoder.com/uncle-bob/images/fpvsoo.jpg https://blog.cleancoder.com/uncle-bob/images/fpvsoo.jpg Take a look at the following video: https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=QM1iUe6IofM While I don't agree with a lot of it, I think it sums up my opinion really clearly. It's not about DP's but because DP's focus around OOP and the video is a criticism of OOP therefore the arguments apply to DPs.
    - james_s_tayler 7y ago
      Thanks. I've observed this as a general trend too. I'm starting to become more and more interested in the functional way of thinking. The image you linked it interesting. I want to dive more in on the how/specifics. I don't necessarily buy the argument it's trying to make that "just make a function and you no longer have a need for factory pattern". You're trying to accomplish something fairly specific with that. Functions compose, I could see how there are properties they have that can be leveraged to achieve the same goal, but I'm guessing the functions you write or the way you write functions to achieve each of those specific aims likely differ in subtle yet important ways. I'm very interested in those details.
      - crimsonalucard 7y ago
        >I don't necessarily buy the argument it's trying to make that "just make a function and you no longer have a need for factory pattern". The same pattern is achievable with functions but the implementation is so trivial in FP that it doesn't even need a name: Just have a function return another function. That's a function factory. Same thing with dependency injection: Just have a function take another function as a parameter. Outside of this I wouldn't even recommend either pattern at all. It's bad practice in all paradigms. Only have data flow through your execution path, don't have new "execution paths" flowing through your execution paths, such architectures tend to be over-engineered.

hhjinks 7y ago

Thanks for the heads up. I'm going to read it soon despite your warnings, but I'll keep what you're saying in mind while going through it.

ngruhn 7y ago
I agree with crimsonalucard but for different reasons. This book is catalog. It's like reading a dictionary from start to finish. This becomes dull fast and you don't learn efficiently. Sure you can just use it to look a pattern up once in a while but then again you might as well read the Wikipedia article.

jamestimmins 7y ago

Could you summarize the different direction that you see things moving?

crimsonalucard 7y ago
Less OOP.