[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 113: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 113: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 113: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
The Nightstar Zoo • View topic - Should an object know how to draw itself?

The Nightstar Zoo

Nightstar IRC Network - irc.nightstar.net
It is currently Thu Jun 27, 2019 7:40 am

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Wed Sep 21, 2005 10:06 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 22, 2005 12:14 am 


Top
  
 
 Post subject:
PostPosted: Sun Sep 25, 2005 10:47 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
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. :-)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Sep 26, 2005 2:13 am 


Top
  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group