Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I would like to implement some kind of manager class in my application. It will be in charge of loading textures, processing them, distributing them etc...

At first, I wanted to make a global variable that simply contains an instance of my manager class. I found this question: However, the users there seem to recommend to never use global variables.

Fine then, I once heard about Singletons, so I though I could use that instead. I mean, creating just one instance of my manager class sounds good. However, I found this other question: When is Singleton appropriate?, which basically tells me that Singletons are, in most scenarios, some kind of anti-pattern.

Now I am a bit lost - what other approach can I take to create my manager class, whose only requirement is to be accessible from anywhere?

share|improve this question

3 Answers 3

up vote 11 down vote accepted

I suggest you look into using a dependency injection framework to achieve inversion of control.

Your "Manager" would not be a traditional Singleton, but you would only create one through the framework configuration. The "Manager" would also not be global, but every component that would need to use it would have it assigned.

share|improve this answer
This is red herring. A DI framework does not impose a better design with less global variables. It will only help you when your design is already a good, decoupled one, to avoid tedious work and some boilerplate code. – Doc Brown Dec 17 '12 at 22:58
@DocBrown: I wouldn't call it a red herring, it's more "necessary, but not sufficient" for good code. It's also a direct replacement for the OP's mentioned solutions. – Steven Schlansker Dec 18 '12 at 8:42
@Steven: Good code uses dependency injection, but not necessarily a DI framework. And I admit, DI is indeed a solution to the OP's question, though a DI framework IMHO has the potential of introducing more problems than it solves, or may be just overkill programs below a certain size. – Doc Brown Dec 18 '12 at 13:29
Sure, not every solution is appropriate everywhere. But a lightweight DI framework like Guice is very easy to set up and use, and has very low cost. It's certainly a good suggestion! But yes, use your judgement... – Steven Schlansker Dec 18 '12 at 19:20
@DocBrown When you accuse this suggestion as being a red herring, do you mean that the real issue the existence of the "Manager" in the first place? Though many (including myself) would agree that it is not ideal, it is common practice in the industry and can certainly fit into a responsible design (dependency injection helps achieve the realization of this design). It even has a name: – smp7d Dec 19 '12 at 17:32

whose only requirement is to be accessible from anywhere?

Did you actually read those two questions?

Having anything accessible from anywhere is design pitfall #1. It tightly couples your manager to your code, preventing that from being as flexible as it needs to be, making the code hard to test, hard to debug, hard to make concurrent...

No. If you must have a manager (I don't personally believe strongly in the link, but it's worth noting) then the app should make one and pass it into whatever needs a factory/manager for your textures/etc.

share|improve this answer

it will be in charge of loading textures, processing them, distributing them

Well, I don't know your application, but this hardly sounds like a thing you need everywhere in your application, especially when your application is layered. You will need it somewhere in your application, and that is where you should pass it, no less, no more.

Moreover, these three responsibilities may be better split up into three classes - one for loading the textures, one for processing them and one for distributing them. The last one is probably the only one some other parts of your application may need to access from outside.

I would also consider to create an interface for your "texture manager", let's call it ITextureManager. The classes/objects needing access to the manager should get passed an ITextureManager instance through their constructor. Later on, you may consider the use of a DI framework, like @smp7d suggested, but actually that does not make a real difference concerning your question - if you are not able to decouple your code from a manager class "manually", you won't be more successfull when trying to use DI framework.

share|improve this answer
+1 - For answering the question but suggesting the better answer that the manager class is not the way to go. If you want to create a manager class, then assume you are wrong. There is almost always a much cleaner, understandable and maintainable way. – Dunk Dec 17 '12 at 23:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.