5 ms·
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
by 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 agoWhat 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 agoThis 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 agoThanks. 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.
- james_s_tayler 7y agoDo 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.
- crimsonalucard 7y agoFunctional 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.