Yes, the characteristics and design of one versus the other are drastically different and do not work well together. Objects lead you to create an object graph (object containing references to other objects) with mutable state distributed all throughout the graph, and that is what constitutes a program. State is shifting sand -- it is always moving underneath you due to mutations (from external method calls on the object). FP uses immutable state where possible and programs look like a tree of functions with data flowing between them. You can examine/modify an individual pure function in that tree in complete isolation -- you don't have to know or care what the rest of the program is doing because its outputs only depend on its inputs. But to get that benefit, you have to design and solve problems slightly differently than what OO programmers muscle memory will be.
I understand what you mean. I'd been stuck with the 'smeared state in objects' rut for a while. I realized that I was just bucketing shared-state without really thinking about the decomposition-goals. I would hesitate to call my mess as object-oriented. It felt more like 'class-oriented random-partitioning'
These days I recognize object-oriented as a caching mechanism, like when UI Widgets need to keep local state to animate/re-draw themselves without a round-trip to the server (like StatefulWidget in Dart). Relationships are more like constraints. Where caching is not needed, a pure function that can be tested in isolation is the way to go!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yes, the characteristics and design of one versus the other are drastically different and do not work well together. Objects lead you to create an object graph (object containing references to other objects) with mutable state distributed all throughout the graph, and that is what constitutes a program. State is shifting sand -- it is always moving underneath you due to mutations (from external method calls on the object). FP uses immutable state where possible and programs look like a tree of functions with data flowing between them. You can examine/modify an individual pure function in that tree in complete isolation -- you don't have to know or care what the rest of the program is doing because its outputs only depend on its inputs. But to get that benefit, you have to design and solve problems slightly differently than what OO programmers muscle memory will be.
I understand what you mean. I'd been stuck with the 'smeared state in objects' rut for a while. I realized that I was just bucketing shared-state without really thinking about the decomposition-goals. I would hesitate to call my mess as object-oriented. It felt more like 'class-oriented random-partitioning'
These days I recognize object-oriented as a caching mechanism, like when UI Widgets need to keep local state to animate/re-draw themselves without a round-trip to the server (like StatefulWidget in Dart). Relationships are more like constraints. Where caching is not needed, a pure function that can be tested in isolation is the way to go!