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.
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.
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.
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".
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?
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.
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.
>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.
Do you have a good example of a reference architecture or implementation of a non-trivial system you can point me to?
I've recently gotten a copy of the book Domain Modelling Made Functional. I'm yet to read it, but I'm pretty intrigued by some of what I've seen and I have heard it comes highly recommend.
I'd be very keen to hear of other high quality examples of things people consider good reference material.
Functional programming is rare. It's sort of like the PS3 when it came out. Better specs across the board but harder to use and understand so it's hard for me to point to production level examples. Facebook does have one big project done in haskell you can look into that. Also whatsapp is done entirely in erlang.
Also note that the trend I see in the industry is not exactly movement towards functional programs but more movement towards borrowing features popular in functional programming as well as getting rid of classes.
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.
Modern programming is heading in a different direction already so it'd be better to move forward without it.