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.
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.