My understanding and recollection from when I dinked with graphic programming is the Visitor is indeed appropriate.
Paul Nathan
2010-04-23 21:59:11
+1
A:
+1
A:
Personally, I'd say to just sort the functions in your files intelligently and that will mostly cover it, but that doesn't sound that that's quite what you're looking for.
You could always put the display-related stuff in one class and the non-display stuff in another and use multiple inheritance. Separating GUI stuff from the logic is quite typical thanks to the MVC design pattern. It's often a great way of doing things, but I don't know how well it applies to what you're doing.
Another possibility would be to just put the the function definitions in separate files. There's nothing requiring you to put all of the function definitions for a class all in one file. Instead of Dog.cpp, you could have Dog.cpp which includes Dog_DisplayFunctions.cpp and Dog_ActionFunctions.cpp or something like that.
Jonathan M Davis
2010-04-23 22:00:35
You ALWAYS want to separate business logic from view no matter what patters or architecture you use to do that. Doing otherwise makes your business logic very difficult to reuse and makes adding or changing views likewise ungainly.
Noah Roberts
2010-04-23 23:59:25
Oh, I agree with that. But if you're doing something really simple for the "view" portion, it might not be worth separating it from the logic. If you're doing anything with any real size to it though, there's pretty much no question that separating the logic from the view is going to a good idea.
Jonathan M Davis
2010-04-24 00:20:33