Is it better to have a public readonly object, identical local readonly objects per class, or to directly reference a library object?

Question

I'm building a game using C# in XNA and I'm not sure which of these four ways is best to refer to the "Viewport" for reading access only:

1. Have a public static variable that every class can access by calling Game.Viewport (Game is the main class:

   public static readonly Viewport Viewport = GraphicsDevice.Viewport;

in use:

rectangle = new Rectangle (Game.Viewport/2, ...

1. Have a local variable that refers to the Viewport for each class that needs the viewport:

   private readonly Viewport viewport = GraphicsDevice.Viewport;

in use:

rectangle = new Rectangle (viewport/2, ...

1. Use a local variable passed down into the constructor of each class that needs the viewport (this would be the only one that didn't require imported Microsoft.Xna.Framework.Graphics):

   private readonly Viewport viewport;

then in the constructor:

viewport = pViewport;

in use:

rectangle = new Rectangle (viewport/2, ...

1. Directly reference the viewport from the class library everywhere where it's needed (in use):

   rectangle = new Rectangle (GraphicsDevice.Viewport.Width/2, ...

I wondering which one is best in terms of speed and which one is best in terms of readability. Personally, I feel like the fourth method would be easiest and fastest so I don't need to create any references to the Viewport and it's clear that I'm referring to something that is global. It seems like it's taking out the "middleman", but then you have to import the XNA graphics library to every class that uses the Viewport.

What do you guys think?

Answer 1

I suppose it depends on your design. If this is just a simple, one-off application, I'd go with your first example. You have a single viewport, none of your classes are dependent on the GraphicsDevice or however you decide to manage that viewport.

Storing the single object there and referencing it in your code will be fast; it's just a field reference so they don't come much faster than that. Calling GraphicsDevice.Viewport every time, especially since it's a property means you'll be running a property getter method every single time you want to access it.

EDIT: If you want to quickly throw in a property wrapper on Game.Viewport (instead of a field) so you can track access (say for logging) temporarily, then you're free to do it this way. If you choose the latter with GraphicsDevice.Viewport , you have to do it every place in your code where you call it (code duplication).

If this is for a more reusable library, if it makes sense to restrict access to your Viewport to only the relevant classes, or want to separate your dependency to Game , passing it down via constructors as dependency injection can be worthwhile, especially when it comes to unit testing.

I wouldn't even consider option 2 (evaluating GraphicsDevice.Viewport for each class as a private field). At the very least you could wrap it with your own reusable static class (which is what you're doing with Game )