The Nightstar Zoo

Nightstar IRC Network - irc.nightstar.net
It is currently Fri Jun 23, 2017 1:54 pm

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?
This came up at work today. Should a class/object know how to draw/render/display itself? Why or why not?

...Should there be a separate rendering class for it? Why or why not?

I have some very strong opinions on the matter. I believe that there is a very clear right-vs-wrong answer to this. But I want to hear what you folks have to say about it. :-)

I'll tell you this much: my answer is a emphatic "it depends". :twisted:


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 22, 2005 12:14 am 
So's mine.

Model-view has merits, most definitely, but I have found that having an object know how to draw itself keeps drawing code, if it's more closely related to the object than the display, with the object. This is as opposed to having it all seperated out to a different module where you've pretty much got to maintain the code for a given object in two places now instead of one (caveat: In The Right Context... it makes no sense to do this sometimes).

That said, I still prefer model-view whenever feasable. We're using this on our current project where all objects are fairly general and while the server does all the actual work the clients merely show the user what happened and take input. Classic.

That is all.


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 
My first and last experience with MFC went about like that.


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:  
Powered by phpBB® Forum Software © phpBB Group