3 ms·

It's maybe confusing because you are presupposing OOP as the default. Humans tend to observe some situation and sythesize stories to explain it, even when it c

It's maybe confusing because you are presupposing OOP as the default. Humans tend to observe some situation and sythesize stories to explain it, even when it comes to observing their own actions. I don't mean to unfairly paraphrase but to transpose what you wrote so it shows these stories you are telling yourself - usually people criticising OOP are "bad programmers" - OOP is easy, alternatives are hard - Even if OOP model is a bad fit, it's still a model and the extra devs needed to solve its bad fit can easily be chained to the oars - If OOP makes trouble, it was because it was "done badly" - Most easy things work well enough even if "done badly" (that is just not true) - If OOP can be cobbled together to work at all, it is justified since that justifies anything If you consider a simpler proposition like, "this can be done in a few hundred or thousand lines of C99 instead of latest C++ and boost", I think there is just no valid reason to bring OOP into it.

scarface74 8y ago
Even when I was writing C, I had different modules in different files, only exposed certain functions via the header files and had structs with function pointers that did different things based on how the struct was initialized. This was before I knew anything about OOP. How is this any different than object oriented programming?
- undreren 8y ago
  It isn't. Not in a significant way at least. I think the main benefit of OOP isn't really abstraction, like modules, because even function signatures coupled to a struct definition can be a great abstraction. Abstraction is about generalizing something in order to hide its inner workings. Modules can do that just fine. What OOP "got right" was to make it easy to use indirection to pass function pointers. That way, you can easily create pluggable systems at runtime, so that strategies can be dynamically chosen. Passing function pointers in c can be pretty tedious, if you need to send implicit state with it. I've started to get really annoyed with indirection though. It's getting abused so thoroughly in order to make bad designs testable through dependency injection. I find that it is much easier to use dependency rejection instead.
  - scarface74 8y ago
    What OOP "got right" was to make it easy to use indirection to pass function pointers. There was the part in my original post... ....and had structs with function pointers that did different things based on how the struct was initialized.

scarface74 8y ago

Even when I was writing C, I had different modules in different files, only exposed certain functions via the header files and had structs with function pointers that did different things based on how the struct was initialized. This was before I knew anything about OOP. How is this any different than object oriented programming?

undreren 8y ago
It isn't. Not in a significant way at least. I think the main benefit of OOP isn't really abstraction, like modules, because even function signatures coupled to a struct definition can be a great abstraction. Abstraction is about generalizing something in order to hide its inner workings. Modules can do that just fine. What OOP "got right" was to make it easy to use indirection to pass function pointers. That way, you can easily create pluggable systems at runtime, so that strategies can be dynamically chosen. Passing function pointers in c can be pretty tedious, if you need to send implicit state with it. I've started to get really annoyed with indirection though. It's getting abused so thoroughly in order to make bad designs testable through dependency injection. I find that it is much easier to use dependency rejection instead.
- scarface74 8y ago
  What OOP "got right" was to make it easy to use indirection to pass function pointers. There was the part in my original post... ....and had structs with function pointers that did different things based on how the struct was initialized.