This part of the article really says it all:
> There is just one little snag… The limits of analogies …When pushed too far, analogies break down.
Anthropomorphism Gone Wrong: OOP
11–20 of 64 posts
Re: Anthropomorphism Gone Wrong: OOP
#12It is really hard to decide on the best way to model, since it doesn't resemble any real-world programming problem.
But OO culture has an unfortunate tradition of using bad examples by using physical objects as analogies for objects in code. Cars, fruits, students, teachers, whatever. Problem is, objects in code rarely correspond to physical objects. In the cases where physical objects are represented, it is most often in the form of database entities, which are typically treated like data-objects, which makes the discussion in the example moot.
Re: Anthropomorphism Gone Wrong: OOP
#13It is really hard to decide on the best way to model, since it doesn't resemble any real-world programming problem. But OO culture has an unfortunate tradition of using bad examples by using physical objects as analogies for objects in code. Cars, fruits, students, teachers, whatever. Problem is, objects in code rarely correspond to physical objects. In the cases where physical objects are represented, it is most oft…
Better examples? Behaviors. States. Event processing machinery. Objects to help support those things.
Containers are also used to demonstrate OO, but they're so abstract only a compiler geek could love them.
Re: Anthropomorphism Gone Wrong: OOP
#14This confuses OOP/procedural semantics with low-level "CPU" work. The argument seems to be that the programming model of a language does not always expose the efficiency of the underlying implementation. And this is also true for "anthropomorphic" models.
Re: Anthropomorphism Gone Wrong: OOP
#15It is really hard to decide on the best way to model, since it doesn't resemble any real-world programming problem. But OO culture has an unfortunate tradition of using bad examples by using physical objects as analogies for objects in code. Cars, fruits, students, teachers, whatever. Problem is, objects in code rarely correspond to physical objects. In the cases where physical objects are represented, it is most oft…
In my experience as a technical instructor -- who frequently has to introduce concepts like the HTML DOM to students who have a hard enough time with markup -- overly simplified metaphors can get over the "can't learn, too hard!" barrier that adults tend to put up when they're expected to learn something new. FWIW, I use the car metaphor, and as a class, we all break it down into simplified properties, methods and events.
Re: Anthropomorphism Gone Wrong: OOP
#16It is really hard to decide on the best way to model, since it doesn't resemble any real-world programming problem. But OO culture has an unfortunate tradition of using bad examples by using physical objects as analogies for objects in code. Cars, fruits, students, teachers, whatever. Problem is, objects in code rarely correspond to physical objects. In the cases where physical objects are represented, it is most oft…
You hit the nail on the head. Objects in OO shouldn't be a projection of the problem domain, they're a way to structure the program (there's some overlap, of course).
Many people seem to get this wrong, probably in part due to introductory examples doing it wrong.
Re: Anthropomorphism Gone Wrong: OOP
#17Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers, which ends up looking like old-fashioned procedural code coated with a sugary OOP shell.
Encapsulation and inheritance and stateful objects have their place, but the "object" metaphor can really lead down the wrong path when taken too literally (as it is in practically every course that starts with "animal" or "shape" or "car" examples).
Re: Anthropomorphism Gone Wrong: OOP
#18I 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 desi…
+1
Re: Anthropomorphism Gone Wrong: OOP
#19Bad 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.
Disagree! If a programmer is good or bad is not a quality separate from how they actually develop programs! A good programmer is good because they choose appropriate tools and methodology etc.
Re: Anthropomorphism Gone Wrong: OOP
#20I 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 desi…
I was also disappointed by the atricle's end: Pretty much only the Dijksta quote was worth reading. The title promised to backup the claim with a real-world experience of OOP, but alas, it did not deliver such.
OOP is better where you code more readably(in comparison with procedural) and where it makes you enjoy coding more. The conditions for when it does that differ from persons to person and from project to project.
I personally like OOP because it helps me focus on different abstraction levels at the same time, and it helps me stay in the flow.