3 ms·

Why is OOP different in that regard? Functional programs can also be spread over many files. The difference between FP/OOP and AOP is that with FP/OOP you know

Why is OOP different in that regard? Functional programs can also be spread over many files. The difference between FP/OOP and AOP is that with FP/OOP you know where to look. References outside the file you are currently looking at are usually declared at the top of the file. While with AOP there are no references in the files that are affected by AOP code.

whizzter 3y ago
There is good and bad OOP, but I think a frequent problem that occurs in _older_ OOP is that when people try to abstract things you end up with functionality in base-classes that can possibly be overriden in subclasses but it might be complicated for reasons and carries extra data, the control flow going from parent->child->parent->child,etc in unfortunate cases (some of this can probably also be attributed to programmers caring more about memory consumption back in the days OOP was popular, leading to many cludgles). With a more functional style you often rather make consumers to pass a function with behavior modifying code, the upside is that the specialization is given from the call-site and that the callee can is more explicit about passing out things without needing to care about the specialization context, and often it's easy to compose specializations in this way in one place.
yakubin 3y ago
Those are not the only options. Old-style procedural structural programming while avoiding unnecessary side effects, globals etc is just fine.
paulddraper 3y ago
A couple reasons this happens in practice. OOP emphasizes encapsulation, decomposition, and dependency injection more aggressively than other paradigms. See SOLID. [1] While not necessarily bad, it does result in more "pieces." Java -- arguably holding the #1 spot for OOP popularity -- requires that each (public) class be in its own file. This results in a lot of files. [1] https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID

whizzter 3y ago

There is good and bad OOP, but I think a frequent problem that occurs in _older_ OOP is that when people try to abstract things you end up with functionality in base-classes that can possibly be overriden in subclasses but it might be complicated for reasons and carries extra data, the control flow going from parent->child->parent->child,etc in unfortunate cases (some of this can probably also be attributed to programmers caring more about memory consumption back in the days OOP was popular, leading to many cludgles). With a more functional style you often rather make consumers to pass a function with behavior modifying code, the upside is that the specialization is given from the call-site and that the callee can is more explicit about passing out things without needing to care about the specialization context, and often it's easy to compose specializations in this way in one place.

yakubin 3y ago

Those are not the only options. Old-style procedural structural programming while avoiding unnecessary side effects, globals etc is just fine.

paulddraper 3y ago

A couple reasons this happens in practice. OOP emphasizes encapsulation, decomposition, and dependency injection more aggressively than other paradigms. See SOLID. [1] While not necessarily bad, it does result in more "pieces." Java -- arguably holding the #1 spot for OOP popularity -- requires that each (public) class be in its own file. This results in a lot of files. [1] https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID