3 ms·

I find the statement is true for either object oriented or functional programming. As someone who has done both extensively, I find that the patterns are still

I find the statement is true for either object oriented or functional programming. As someone who has done both extensively, I find that the patterns are still applicable to both. The presentation is very different, but still viable. For instance, you might use recursion to traverse data over a for-loop, but that doesn't inherently change the concept of a data "structure". No matter what, we're still speaking in design patterns and if we share that common language, we can apply it to a domain and solve the larger problems of our day-to-day. If you want more examples of this, look up Data Driven Development, but also append Haskell or C++ to your search queries, you'll find they repeat the same concepts in two very different "grammars"... ahem... I mean "languages".

travisgriggs 3y ago
Yes, given the downvotes, I fear my comment may be misconstrued as a function(al) bash. I write lots of Elixir these days. And see the same issues. All I was trying to say is that, my experience in OOland, that was hyper focused on this idea, gave me lots of opportunity to see that while this rule is obvious and good and everyone wants to do it, I observed that for many programmers decomposing complex data structures is a very non-intuitive task, and difficult to actually realize this rule.
- cowl 3y ago
  The downvotes are most probably becasue data structures have nothing to do with the concepts of OOP. the datastructures stand on their own and have been present long before the concept of OO came about. yes you can model them as classes/objects to incapsulate the set of operations that you can do on them but it's not mandatory and certainly does not require any concept of inheritance, mixins etc.