I look at that and it looks like gobbeldygook.
Just because a design is greatly simplified, doesn't mean it is good. Assembly language is greatly simplified, but you would not write a game in it. OOP is greatly simplified in a different way, but is it a good way?
I could write a keyboard class that you could glance at and know intuitively how to use it almost immediately.
But I look at that, and you say you can use it for any type of input, but I can't see how to even use it for the keyboard. (I'm sure I could figure it out if I wrangled with it for a half hour, but that's the point. I shouldn't have to do that.)
It does you no good to make a class which can return the same input states for any number of different devices, if the code cannot be quickly and easily grasped fully.
If the point of OOP is to make it so other people can grasp your code so as to have a clear picture of what is going on in the program, then OOP appears to fail in this regard. If the point of OOP is only to make it harder to make buggy code, then I have not seen it do that, and at what cost? Hundreds of additional hours of people trying to figure out what the code does? Doesn't seem like a good tradeoff to me.
Also, I question the usefulness of this approach. A mouse is not a keyboard. A network is not a keyboard. A mouse is analog. A network has lag. You cannot simply pull an "up" state off a network and apply it to a player and have that work well. You might need to work under the assumption that that input was applied by the player 200 milliseconds ago, and calculate their current position based on that assumption.
Some things are better left unsimplified. Or at least, not oversimplified.
Anyway, I just don't see how you could say that doing something like this would require a less intuitive approach without OOP. You could so something like this with procedural programming and it would be way more intuitive.
There's a reason why Basic languages don't use OOP methods. OOP is less iniuitive than procedural programming. I taught myself procedural programming. Thus far I've failed to teach myself everything there is to know about OOP, and what I have learned about it so far is only thanks to people explaining it to me here. You might say I should have picked up a book on it to learn it, but if I have to do that itself is proof it is unintutuitive. Intuitive is derived from inituition, not from "read a book on it".
Just because a design is greatly simplified, doesn't mean it is good. Assembly language is greatly simplified, but you would not write a game in it. OOP is greatly simplified in a different way, but is it a good way?
I could write a keyboard class that you could glance at and know intuitively how to use it almost immediately.
But I look at that, and you say you can use it for any type of input, but I can't see how to even use it for the keyboard. (I'm sure I could figure it out if I wrangled with it for a half hour, but that's the point. I shouldn't have to do that.)
It does you no good to make a class which can return the same input states for any number of different devices, if the code cannot be quickly and easily grasped fully.
If the point of OOP is to make it so other people can grasp your code so as to have a clear picture of what is going on in the program, then OOP appears to fail in this regard. If the point of OOP is only to make it harder to make buggy code, then I have not seen it do that, and at what cost? Hundreds of additional hours of people trying to figure out what the code does? Doesn't seem like a good tradeoff to me.
Also, I question the usefulness of this approach. A mouse is not a keyboard. A network is not a keyboard. A mouse is analog. A network has lag. You cannot simply pull an "up" state off a network and apply it to a player and have that work well. You might need to work under the assumption that that input was applied by the player 200 milliseconds ago, and calculate their current position based on that assumption.
Some things are better left unsimplified. Or at least, not oversimplified.
Anyway, I just don't see how you could say that doing something like this would require a less intuitive approach without OOP. You could so something like this with procedural programming and it would be way more intuitive.
There's a reason why Basic languages don't use OOP methods. OOP is less iniuitive than procedural programming. I taught myself procedural programming. Thus far I've failed to teach myself everything there is to know about OOP, and what I have learned about it so far is only thanks to people explaining it to me here. You might say I should have picked up a book on it to learn it, but if I have to do that itself is proof it is unintutuitive. Intuitive is derived from inituition, not from "read a book on it".