Skip to main content
GameDev.net gamedev.net
🔒 Locked

Question Regarding Tools

Started by Palidor Sep 4, 2009 at 1:06 PM 0 replies 950+ views
Original Post
Palidor
Palidor
Hi everyone! We've been working on a side project where we've been creating our tools using C# and a C# OpenGL wrapper. The problem being encountered is one of correct design, and making the tools extensible so we don't have to hack around everything when we want to extend on it. With that being said, I wanted to detail the main problem we are encountering: I'm not sure if it was because of classes at school, or general design decisions, but we have been embedded the actual data into the controls themselves. So, for example, if a numeric up down changes, we then handle that event, and inside that control's event handle function, we not only send events to other controls that the value changed, but we change the data embedded in that control. As a result, if the data embedded in this control is part of a larger object containing it, then another control will contain the larger objects. This means that not only would update the information stored in the smaller control, but you'd have to update the information store in the larger control as well. This seemed like not only an exponential waste of memory, but processing time as well. My question here is, what is a good design strategy to solving the problem? One idea i had was creating a singleton that stored all possible data used in the entire system, and then have the controls directly alter or get data from the singleton, thus meaning if a smaller control changes the data, it will be reflected in larger controls without having to store it everywhere. Is this a valid strategy, and if not, is there a better someone can suggest? Also, embedded data everywhere seems to be a very bad idea as well because it seems that passing List<"class name">'s around is favored very highly in designer due to serialization issues... Thanks in advance everyone!
DCM
DCM
I don't do a whole lot of tool programming but I would research the MVC design pattern approach, i've used it when making tools in the past and tends to produce more robust results. There is a specific pattern used extensively in MFC windows programming (often used to make tools) that is escaping me at the moment, but the concept i remember to be similar.

the basic jist of the pattern is very simple where you decouple your application into three modular parts - model, view and controller.

model is your data

view is how your data is displayed

controller is how the user creates/modifies data

generally when a tool is made you are trying to modify or create raw data for export through a visual interface.

this general assumption is why mvc lends itself well to tools, you have your core data set that you can load in and out of the tool, you have your controller which handles how your interface deals with user input, and your view which simply takes data and displays it.

the general idea is that by doing this you limit your dependencies and create more flexible and easily extendable code. If done correctly you can for example turn your view module on and off without effecting the controller or the model.

relative to your issues, with embedded data everywhere, this will centralize all your data into the model making it easier to maintain your data as well as simplify and create a clear interface for how your view and controllers interact with the data.

mvc in application is a bigger pattern than a singleton, so its not to say using a singleton pattern is a bad idea, or that you wouldnt use it in some form in your tool or in conjunction with an mvc style implementation - but i would still say in terms of design pattern education to give mvc a look - if anything to expand your horizons.

Hope this helps you, it's easier said than done but I'm sure there are plenty of references to the pattern here or on google if you decide to research further for a more concrete description and implementation of the pattern.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.