0

Lets say, I have a class named Texture that realizes the RAII-idiom. Furthermore I have a corresponding TextureManager class, that instantiates and deletes Texture objects. Its a 1-to-1 relationship: Each TextureManager instance creates one particular Texture object when it is time to do so and it deletes it when it is not required any more. The TextureManager decides this.

The point is that I'm not happy with the name of the TextureManager class. I think it is too vacuous, for two reasons:

  1. The name TextureManager does not reflect the 1-to-1 relationship of a TextureManager object and the Texture object it creates/deletes.
  2. The name is misleading. It could be understood as a class that loads textures from hard drive.

I've thought of a few alternatives, that I'm not happy with either:

  • TextureControl does reflect the 1-to-1 relationship in my opinion, but it sounds more like the name of class that actually controls existing instances.
  • TextureLifetimeControl would be self-explanatory, but it is long and inelegant in my opinion.
  • TextureHolder does reflect the "possessing" nature of the the 1-to-1 relashionship, but it sounds more like an object that takes an existing instance and keeps it to me.

Any suggestions?

theV0ID
  • 4,172
  • 9
  • 35
  • 56
  • You could use "Texture" instead of "TextureManager" and "TextureData" instead of "Texture". So the user manipulates a texture without knowing it is actually a manager containing a texture. I don't know if what I mean is clear... – lodo Mar 24 '15 at 12:29
  • @lodo Intresting Idea. I'm not happy with `TextureData` because this sounds more like the source of a texture to me, but maybe `TextureObject` would be an option. – theV0ID Mar 24 '15 at 12:31

0 Answers0