I think you're talking about rendering classes, iirc, Raif. That's one of the few places I would say yes.
An object should know how to draw itself if and only if its job is to draw itself
. Classes like "Line2d" and "TexturedPoly" are good examples.
Model/View is a good thing, where good varies exponentially with the size of the project. By this I mean that if I'm writing something under 1kLOC, it will probably break the above self-rendering rule. But this has nothing to do with the rule: I tend not to exert M/V separation (or even strong class structure) on tiny projects.
Objects in the problem domain got no business knowing anything about anything going on in the human interaction component. It's real easy to tell, as well: you can't really describe your real world object in terms of real world anymore. "This is a Hero object. He knows how to move and attack, and he knows how much gold he is carrying. Oh, and he knows how to draw himself onto a 24-bit texture surface with alpha transparency...."
In 3D graphics land, this split can be hard to maintain, especially since there's so MUCH View data and so little going on in the Model. But it's there all the same. Positions and animation frames and texture arrays belong in the View, but hit points and high scores do not.
In the business world, the reverse case is far more common: views that know too much about the objects they are rendering. They don't contain all
of the object data, but they'll get wayyyy too much knowledge packed into them. This is especially prevalent in IDE-based GUI development, where it's so easy
to start injecting code into a form (a View class!) that you end up crossing the line. My current work involves a Java project written with the Eclipse IDE that has fallen to this sin. ATL seems to encourage proper separation, but MFC was a hotbed of forbidden object knowledge. Don't even
get me started on Visual Basic: I coded VB professionally for 10 years and I don't think I ever saw a proper M/V split. (I wrote quite a few of those projects, but that was before I knew better. I was young and I needed the money.)
My raging about the business version of blurring the M/V line is what prompted the discussion that raised the above post. It's too easy to open the onClick handler for a form and start writing code that the form really doesn't have any business knowing about. We needed to get some objects from the database, process them, and display the results. And of course, the onClick handler did it all.
I did a good bit of refactoring that day.