"Many functions operating upon few abstractions" principle vs OOP
clojure, functional-programming, oop, reusability
Solution
There are two main notions of "abstraction" in programming:
- parameterisation ("polymorphism", genericity).
- encapsulation (data hiding),
[Edit: These two are duals. The first is client-side abstraction, the second implementer-side abstraction (and in case you care about these things: in terms of formal logic or type theory, they correspond to universal and existential quantification, respectively).]
In OO, the class is the kitchen sink feature for achieving both kinds of abstraction.
Ad (1), for almost every "pattern" you need to define a custom class (or several). In functional programming on the other hand, you often have more lightweight and direct methods to achieve the same goals, in particular, functions and tuples. It is often pointed out that most of the "design patterns" from the GoF are redundant in FP, for example.
Ad (2), encapsulation is needed a little bit less often if you don't have mutable state lingering around everywhere that you need to keep in check. You still build ADTs in FP, but they tend to be simpler and more generic, and hence you need fewer of them.
Problem
The creator of the Clojure language claims that "open, and large, set of functions operate upon an open, and small, set of extensible abstractions is the key to algorithmic reuse and library interoperability". Obviously it contradicts the typical OOP approach where you create a lot of abstractions (classes) and a relatively small set of functions operating on them. Please suggest a book, a chapter in a book, an article, or your personal experience that elaborate on the topics: - motivating examples of problems that appear in OOP and how using "many functions upon few abstractions" would address them - how to effectively do MFUFA* design - how to refactor OOP code towards MFUFA - how OOP languages' syntax gets in the way of MFUFA *MFUFA: "many functions upon few abstractions"