I don’t think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let’s add encapsulation and implementation hiding to this list.
The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore
It is difficult to understand: the developer has to open two, three or more different classes to view the whole algorithm
It is inefficient: because the algorithm is distributed over many classes and instances, as the algorithm runs, there are a lot of unnecessary calls (eg one method on one instance has to iterate over many instances of its children, and each child has to iterate over its children) and data has to pass through these function calls.
Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it’s the function that walks the object structure. The navigation is done using tools like apply or map rather than a loop in a method on the parent instance.
A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.
In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object’s private members, or data processing for that object and its immediate children or peers.
Sounds reasonable to me: With what I’ve written I don’t think I’ve ever been in a situation like the one you describe, with an algorithm split over several classes. I feel like a major point of OOP is that I can package the data and the methods that operate on it, in a single encapsulated package.
Whenever I’ve written in C, I’ve just ended up passing a bunch of structs and function pointers around, basically ending up doing “C with classes” all over again…
Indeed, I’d say an algorithm split among different objects is usually an indication of tightly coupled code. Every code pattern has its pitfalls for inexperienced devs, and I think tight coupling is OOP’s biggest.
I don’t think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let’s add encapsulation and implementation hiding to this list.
The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore
Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it’s the function that walks the object structure. The navigation is done using tools like
applyormaprather than a loop in a method on the parent instance.A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.
In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object’s private members, or data processing for that object and its immediate children or peers.
Sounds reasonable to me: With what I’ve written I don’t think I’ve ever been in a situation like the one you describe, with an algorithm split over several classes. I feel like a major point of OOP is that I can package the data and the methods that operate on it, in a single encapsulated package.
Whenever I’ve written in C, I’ve just ended up passing a bunch of structs and function pointers around, basically ending up doing “C with classes” all over again…
Indeed, I’d say an algorithm split among different objects is usually an indication of tightly coupled code. Every code pattern has its pitfalls for inexperienced devs, and I think tight coupling is OOP’s biggest.