   Need some advice on code redesign (long)
  (The language I'm using is C++. Also, sorry for the long post, but I wasn't sure if the problem would make sense without context.)My current project is a simple little D3D wrapper that will be the eventual base for an equally simple little game engine. I'm mostly done at this point, but I've been trying to refactor my code to fix up some annoying little design issues that might end up bothering me in the future. Specifically, I've been trying to make sure that each class relies on the fewest number of other classes possible.Right now, there are two big classes that are the basis of the whole thing: CFramework and CD3DManager. CFramework makes use of my Win32 wrapper classes to create and display a window to render to, run the message pump, and eventually clean up the windows junk and end the program. It makes use of wrapped function pointer objects to add in any additional initialization, main loop, or cleanup code. The end result is that winmain ends up having code like this in it:// CFramework is a singleton, but maybe it doesn't have to beCFramework* app = CFramework::GetInstance();app->SetConfig(myConfig);app->SetInitCode(&CGameCore::init);app->SetMainLoop(&CGameCore::main);app->SetCleanupCode(&CGameCore::end);app->InitializeApp();// Runs the main loopapp->RunApp();app->ShutdownApp();In reality there's a bit more going on (setting up the config object, for example), but you get the idea. CD3DManager isn't a singleton, since I figured the only place you need access to it is inside the rendering code. The idea is that you instantiate an instance of it somewhere, call the CD3DManager.Initialize() method (probably in the function you pass to setInitCode), and then treat it like a simple wrapper around D3D. Any other wrapped objects (meshes, etc.) are generated by CD3DManager and it deals with cleaning up those resources.So what's the problem? I'm having 'issues' with something that should be incredibly simple: my timer. The idea was for CFramework and CD3DManager to be completely independent of eachother - no coupling whatsoever. I want to be able to use CFramework without CD3DManager and vice versa. Likewise, the code that gets passed into CFramework should have no idea that CFramework exists. The timer class is making this more difficult than it should be.The problem is that CFramework.RunApp() is actually the main program loop -  including the message pump. In order to properly figure out the elapsed time between frames, the timer has to be started before RunApp() checks for and dispatches messages and ended after the main loop code passed into CFramework ends. Both of these things have to happen inside of CFramework.RunApp(), but the actual elapsed time generated by the timer is only useful elsewhere (in the rendering code or wherever).I'm not sure what the best way to deal with this is. I can make the timer part of CFramework so that other objects call a GetDeltaTime() method on CFramework, but this makes the code dependent on CFrameWork. The only other thing I can think of is to make the timer a singleton itself and then have CFramework call the StartTimer() and EndTimer() methods while anything that relies on the timer calls GetDeltaTime(). This also seems less than ideal, since code can accidently screw things up by starting or stopping the timer outside of the main loop. Not a big deal in practice (I'll probably be the only one using all of this), but shitty design nonetheless.At this point, it seems like these are my only two options, but I'm hoping that I'm missing something.Edit- I should mention that, right now, my timer is a singleton, so I'm using my second idea in practice at the moment. That's what I'm trying to redesign. It works fine, except for the potential pitfall that I mentioned.   
  I assume that CGameCore knows about your rendering wrapper.Your main loop looks probably something like:DealWithInput();UpdateObjects(DeltaTime);RenderObjectsUsingWrapper(DeltaTime);With this assumption IMHO CFrameWork should not even know about timers, but instead it should be the CGameCore class which deals with the timer and pushes the delta time to the systems interested.Hope this helps   ;  Its sort of difficult to understand exactly what your architecture looks like from the description - but stepping back from it a bit I would ask myself a few questions:"Am I letting greatness get in the way of good enough?"  I am a perfectionist, and compulsive (which I am told are 2/3 of the trinity for being an @ss - but thats another topic) so I understand the urge to always be messing with things.  However, If there is no real good reason for the change - leave it and start building the game/other features/etc..."Are items in the D3DManager requiring access to the timer object, or do they just need to know the time?"  I dont quite understand why there would be an issue with having the timer be a singleton, but if all the Manager needs is a deltaT - then pass the time vice the timer object."Would redesigning this to get the architecture I want uneccessarily complicate the cleanliness and maintainability of my code?"  This is sort of an ode to Q1, but more of a sanity check.  What may be a good decision at first, in the end, may be more trouble than it is worth.  Micro examples are, "NEVER use goto" and "Public data types are BAD!  Never use them."  People who adhere to rigid and unforgiving dogma tend to be worse off than those who try avoid poor habits but understand that in some cases it provides a more elegant solution.  The point here is be careful what you ask for - you might start tugging at the yarn of the sweater and end up with a pile of yarn again.Good luck...#dth-0;Quote:Original post by xiuhcoatlIts sort of difficult to understand exactly what your architecture looks like from the descriptionYeah, I'm not all that great explaining things. I almost included a diagram, but the post was getting long enough already.The real gist of things is that CFramework is just a generic program skeleton. It was my attempt to take the utility code that everyone makes to save themselves typing and turn it into something even more generic that I could use for small projects.The only reason I'm so concerned about keeping the rest of the program completely separate from it is the possibility that I'll want to ditch the framework at some point (for whatever reason) in favor of something else. If I decide to do that midway through a project, I'd like to be able to just cut the CFramework object out completely while changing a minimal amount of code elsewhere.Quote:"Are items in the D3DManager requiring access to the timer object, or do they just need to know the time?"  I dont quite understand why there would be an issue with having the timer be a singleton,You're right - there's no reason why the timer object can't be a singleton, other than it doesn't seem like it should be. No other part of the code besides the framework will have to start and stop the stopwatch.Quote: but if all the Manager needs is a deltaT - then pass the time vice the timer object.This is a good point. I don't know why I didn't think of this before, but I can implement a 'Time' object to act as a mediator between the timer and the rest of the program. The timer updates the time object and the rest of the code can poll that object for the deltaT. This way only the framework has access to the timer and the rest of the code doesn't have any direct link back to the CFramework object itself.Your whole post was really helpful. Thanks a lot, man. [smile]   