You have to change how you read code. Stop worrying about implementation details and see the objects API, and stop digging into every method, you don't need to see the implementation all the time. Step back, look at the classes and the messages between them and ignore the implementation whenever possible. When you understand how the parts work together, then you tend to know which part is broken for any given bug, and you know you can ignore most of the other parts entirely.
Yes it's a good thing, because such programs are simple and pluggable allowing you to add features by adding new classes rather than modifying and potentially breaking existing ones.
But they're not simple. The complexity is still there, it's just distributed and difficult to trace.
I much prefer the functional way of doing things. The complexity is still minimized, but I can see where things are coming from, and how data is composed.
While it's harder to add "cases" to types in the functional style, I find myself wanting to add functions over types far more often, and therefore, I find that it works far better for me.
Of course do what works for you. But distributed is the wrong word in a sense, the complexity is broken down into simpler parts that aren't complex, that's the point. If you're unwilling to adapt your reading style, then you won't see the benefits because your thought process isn't congruent with the style.
You clearly prioritize data over behavior, so naturally functional code fits your thought process better, but your though process is one among many. OO works well when your thoughts are behavior centric rather than data centric.
What I prioritize is the ability to quickly and easily answer the question "Where is the bogus value coming from?". When the inputs building up the value are spread all over the place, it's annoying to trace.
When you know how the parts work, you don't have to trace it. 99% of the time, I see a bug, I know what's broke, because I understand the program at a high level and know X just can't happen anywhere but Y. Object oriented programs are not a sequence of data transforms, if you insist on thinking of them that way then of course you're going to dislike OO. I've never had any of the problems you're relating to me, because I embraced a change in how I think when I changed to OO.
If you insist on thinking functionally or procedurally, well, then OO won't agree with you because you won't let it. You want to see everything in one place so you can see the big picture all at once; if that works well for you great.
But there's another way that we like, rather than seeing everything crammed into one spot in a complex way, we break it down into many small parts that are each individually stupidly simple. Each part assigned a responsibility in completing the overall task, and each part pluggable with any part having the same interface. The big picture is in the message names between the parts and the part names themselves, and the actual code implementing those messages is basically irrelevant. We find this simpler precisely because we can ignore everything but the one part we're working on, which is stupidly simple. And we can easily extend the system buy subclassing any part to change the behaviour of the program without touching the existing parts, but simply by adding new ones.
Quite simply, we don't want everything in one place, it's inflexible, brittle, not pluggable, and not simple in the way we define simple.
If that's what you need to tell yourself. You seem like the typical OO hater, uninterested in grokking it, just interested in justifying your dislike with a bunch of hand waving about how you think it's complicated without presenting an alternative that has the same flexibility. As you've not added anything interesting to the conversation, I don't care to continue it; good day.
Yes it's a good thing, because such programs are simple and pluggable allowing you to add features by adding new classes rather than modifying and potentially breaking existing ones.