3 ms·
Your first paragraph makes some sense, but I truly disagree with your second. Good OOP design is very similar, if not identical, to good FP design. For example
by edejong 11y ago
Your first paragraph makes some sense, but I truly disagree with your second.
Good OOP design is very similar, if not identical, to good FP design. For example:
- The iterator pattern: is essential to more abstract FP, see for instance 'the essence of the iterator pattern: https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf' https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.... The iterator as a stream is a coinductive data structure and a such a fundamental structure in FP. Also note that transformations on iterators are applicative.
Then, look at many of the other GoF structures: the visitor pattern, which is very similar to recursive algorithms on trees. The adapter is basically applicative, the Factory is difficult, but could be seen as a coinductive structure.
Also, one should note that in (modern) proper OOP, composition is your most important tool. This is very similar to composition of functions.
- nickbauman 11y agoYou picked an especially bad pattern for your proof. Iterators aren't inherently functional. In the imperative world they needlessly maintain state and are by nature one giant side effect. Data abstraction doesn't even require an iterator "pattern" to achieve iteration, that's the whole point of data abstraction that a "pattern" isn't required but merely a "concept". In Clojure, for example, the concept is a sequence which has stateless traversal. That paper you quote even makes the distinction between the separate approaches taken from functional versus imperative.
- paulddraper 11y agoThink C++ iterators. Those maintain state, but not mutable state. You have full control over the iteration,. but everything is immutable and thread-safe.