>I agree that in many cases there is a problem, and indeed, objects can be designed as too coarse.
Or don't put your methods in an object at all. Then you don't need to even worry about everything being designed coarse because your object doesn't even exist in the first place.
>Objects naturally group related functions in some cases (when they truly conform to a coherent entity), so I guess I disagree they are always wrong.
Think of it like this: You can build a lego project by gluing all the pieces together (aka OOP) but I would say this is always wrong because if you just connect the pieces together without glue they will stick together but they can be split apart at the same time. In OOP your mistakes may not be evident until years later, OR changing requirements make the glue hard to remove...
Thus I say it's always wrong to use OOP. Just don't glue anything together. Leave it all decoupled. There's no point to bring glue to a lego set.
>Functions can fall prey to the same faulty thinking. I've seen many times functions "in the wild" that do too many things, tweakeable through too many parameters. They usually must be refactored.
So? It's not like Taking the SAME function and placing it in an Object doesn't solve this problem. This problem you describe is completely orthogonal to the issue I'm describing because it exists in your logic independent of whether or not that logic is a method or a function.
>In fact, refactoring is where you split objects that have become too large or ill-defined for their own good, is it not?
Yeah, If your logic was a collection of functions you don't have to spend the inordinate effort to remove the glue. All you need to do is recompose the lego building blocks in a different way because there wasn't any glue holding it together (if you didn't use OOP)
>In the end, I think this is more about good software engineering practices rather than "one must use/must not use OOP/FP" or whatever ?Programming style.
I didn't specify FP here. OOP is NOT good software engineering practice is what I'm saying here.
Or don't put your methods in an object at all. Then you don't need to even worry about everything being designed coarse because your object doesn't even exist in the first place.
>Objects naturally group related functions in some cases (when they truly conform to a coherent entity), so I guess I disagree they are always wrong.
Think of it like this: You can build a lego project by gluing all the pieces together (aka OOP) but I would say this is always wrong because if you just connect the pieces together without glue they will stick together but they can be split apart at the same time. In OOP your mistakes may not be evident until years later, OR changing requirements make the glue hard to remove...
Thus I say it's always wrong to use OOP. Just don't glue anything together. Leave it all decoupled. There's no point to bring glue to a lego set.
>Functions can fall prey to the same faulty thinking. I've seen many times functions "in the wild" that do too many things, tweakeable through too many parameters. They usually must be refactored.
So? It's not like Taking the SAME function and placing it in an Object doesn't solve this problem. This problem you describe is completely orthogonal to the issue I'm describing because it exists in your logic independent of whether or not that logic is a method or a function.
>In fact, refactoring is where you split objects that have become too large or ill-defined for their own good, is it not?
Yeah, If your logic was a collection of functions you don't have to spend the inordinate effort to remove the glue. All you need to do is recompose the lego building blocks in a different way because there wasn't any glue holding it together (if you didn't use OOP)
>In the end, I think this is more about good software engineering practices rather than "one must use/must not use OOP/FP" or whatever ?Programming style.
I didn't specify FP here. OOP is NOT good software engineering practice is what I'm saying here.