Anthropomorphism Gone Wrong: OOP
loup-vaillant.fr
Anthropomorphism Gone Wrong: OOP
1–10 of 64 posts
Re: Anthropomorphism Gone Wrong: OOP
#2[deleted]
Re: Anthropomorphism Gone Wrong: OOP
#3The author is missing maybe the following point: when there will be multiple objects that need to move, and some of the move methods will require state, then it will be nice to encapsulate the state within objects, rather than having messy global state and methods that access a global state... which can lead to coupling between methods, if not concurrency issues, and before you know it, you end up with hard to understand, non-maintainable, non-refactorable spaghetti code.
Re: Anthropomorphism Gone Wrong: OOP
#4Regarding Dijkstra's quote: our brains are wired to model people with internal desires... sometimes it can lead to some errors, like animism, but if used correctly, it can be a powerful technique.
I've designed concurrent systems with many processes talking to each other. Each process has a name that describes a profession, owns certain parts of a shared database and transacts with other processes.
Sure that analogy can break down in the limits, but thinking like this allows me to get a much clearer mental picture of what's happening.
Re: Anthropomorphism Gone Wrong: OOP
#5One obvious problem with that comparison - it is a toy example.
It is really not about anthropomorphizing objects, it is about where the state is kept and who can modify it how. And the right or at least the best choice heavily depends on the problem you are modeling. If you are primarily tracking the whereabouts of students it is probably a good choice that students keep track of that information and provide an interface to update it. If you are primarily interested in rooms and who is inside, it may be better to make the rooms responsible and provide an interface like classroom.enter(student).
Re: Anthropomorphism Gone Wrong: OOP
#6Bad programmers write bad programs. It's not methodology. Good programmers have successfully written a lot of software in an OO design. That doesn't mean OO is the best solution for you, it just means that you can't judge a book by its cover, and in this industry, we're covered in bad programmers.
Re: Anthropomorphism Gone Wrong: OOP
#7I was disappointed by this article in the end. I was ready for a good old fashioned OOP bash, supported by strong opinions and examples. We should always remain open to new (or old, in this case!) patterns. Instead we get a "tie" given a very simple (not real world) example.
In the end I'm left with the same conclusion. Given that there is no obvious performance gain from a procedural approach, I would opt for a design pattern that is friendlier to the programmer (the human being). It's helpful to model things this way as an organizing approach. And there are obvious benefits to maintaining state within their respective concerns.
It isn't to say OOP is the only and best answer. It very much depends on the program, but I was hoping for a more obvious win on the procedural side here.
Re: Anthropomorphism Gone Wrong: OOP
#8I think the procedural option is better. It is just so much less code.
Re: Anthropomorphism Gone Wrong: OOP
#9I think the procedural option is better. It is just so much less code.
[deleted]
Re: Anthropomorphism Gone Wrong: OOP
#10still i would like to see a concrete example where OOP is better. I thought that OOP had advantages in larger projects with many kinds of data where it helped organize the code to make it more readable and editable. At that point you need to be careful how you use it to make it manageable. Not sure how small an example would could be before it started to show some benefits.