   OO Design Question
  I'm currently working through Introduction to 3D Game Engine Design Using DirectX9 and C#, by Lynn Harris, and I have a question about a design decision that he evidently made for the book.In the book, he creates a heirarchy of classes that comprise a game engine for an outdoor racing game.  The highest level class I have seen thus far is GameEngine, and it contains variables representing many of the other classes created throughout the book.  SplashScreen is an example, and it is its Render function about which I have questions.The Render function performs several tasks, such as enabling fog, setting textures, etc.  For these tasks, it is obvious that one would need a reference to a Direct3D.Device.  In the book, Lynn creates a property in GameEngine that returns that Device, and SplashScreen.Render uses this property heavily.  This translates into SplashScreen "knowing" about the higher-level class GameEngine.  To me, this seems wrong.I can only think of one way that I would feel better about the OO design, and that would be to pass a reference of the device (through constructor parameters or a property) to the class, and leave the class ignorant of any class that may use it.OO Design is something with which I really struggle, and I want to get this right.  So I ask, which approach, if either, is better and why?  If both approaches have flaws, what is another approach?I really appreciate your help.   
  Sounds like use of existing design patterns to me...see these:Dependency InjectionInversion of ControlTry doing Google searches on these for more info.   ;  You could be right - often these game books will use questionable code to demostrate a particular aspect.The reason I expect the book has done it like that is because they didn't want to encourage keeping multiple references in different places - which is very bad in OO land.Personally speaking I would probably just pass the device reference to the function that requires it when it's called by the GameEngine - that way there's only one reference being kept at class level, and the rendering thing doesn't need to know about GameEngine because it's getting what it needs.   ;  Thanks for the speedy responses.  I've implemented both and am much happier with the result.   ;  Another point of view:If it works, isn't buggy, and you can still maintain it, then it's not broken and doesn't need fixing.Once you get a bug because it's so complex you can't maintain it, and thus it doesn't work, then you know you need to fix it by clearing up whatever the muddiest parts are. Don't do work you won't have to do, until you have to do it. Design is work, too! (in fact, hard work!)   