211–220 of 252 posts
> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…
Earlier quoted context omitted.
> What probably is true however is that a lot of people should unlearn the OOP they learned in school. Can you provide references for proper OOP?
The Java Swing API is a good example of OOP done well.
https://docs.oracle.com/javase/7/docs/api/javax/swing/JButto...
Earlier quoted context omitted.
Great point... but doesn't it continue to prove the author's point that this is needlessly complex? It strikes me as bad design if something as simple as an action (hit) now needs to become it's own class that is instantiated merely to execute a single function and then have to delete itself. That just feels like insane overhead/boilerplate, no? The argument here is that it's far better to have player and monster be…
And you end up having functions that look like. hit(player, monster, weapon, damage_modifier, arena, previous_turn, next_turn, global_modifiers) because the author didn't like, or understood encapsulation.
Poor design has a way of cutting across programming paradigms, or even (in the case of inappropriate inheritance, for example) leveraging their features.
Earlier quoted context omitted.
I agree Python is good for teaching, but the maintainability and type safety aren't features of the boilerplate. This is clear when considering languages like OCaml, Haskell and other languages featuring type inference.
Python has an external static type checker with type inference.
This is coming from a business consultant (BA/PM and configuration primarily), but in my experience, it seems like the OOP paradigm is fine in most cases and is leveraged in a functional/compositional fashion typically, so I fail to see the issue with OOP a paradigm. Generics and polymorphism can be used to basically create a functional system that only uses domain specific classes to handle edge cases. In short, OOP…
What is the point of OOP then, if you are using it in a functional way ? This just proves author's point. Do you truly use it in a functional way though, that would mean, that you care about separation of state and identity. If you are mostly using immutable collectons/objects with pure functions, then it's fine, but this is not OO.
Earlier quoted context omitted.
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…
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?
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.
> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…
Great point... but doesn't it continue to prove the author's point that this is needlessly complex? It strikes me as bad design if something as simple as an action (hit) now needs to become it's own class that is instantiated merely to execute a single function and then have to delete itself. That just feels like insane overhead/boilerplate, no? The argument here is that it's far better to have player and monster be…
Earlier quoted context omitted.
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?
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, yo…
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.