7

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: https://stackoverflow.com/questions/4646577/global-variables-in-java. 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?

Improve this question

3 Answers 3

Reset to default
13

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.

Improve this answer
5
  • 2
    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
    Commented Dec 17, 2012 at 22:58
  • 2
    @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
    Commented Dec 18, 2012 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
    Commented Dec 18, 2012 at 13:29
  • 1
    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
    Commented Dec 18, 2012 at 19:20
  • 1
    @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: martinfowler.com/eaaCatalog/transactionScript.html
    – smp7d
    Commented Dec 19, 2012 at 17:32
4

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.

Improve this answer
4

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.

Improve this answer
5
  • +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
    Commented Dec 17, 2012 at 23:07
  • @Dunk I agree but sometimes it is really just a matter of choosing the correct naming. In this case it might be better referred to as TextureStorage or TextureLoader etc..
    – LegendLength
    Commented Jan 6, 2016 at 5:16
  • @LegendLength - In software; names matter, a lot. It really isn't just what you called it. If you choose the proper names then decisions become much easier; new people learn the system much, much, much faster; you won't have to spend days relearning what you did 6+ months ago when they decide your app is worth updating. If you give an object/module a concrete name then it is clear what that module should and shouldn't do. If you tack on the word manager, then all of a sudden anything even tangentially related is valid to throw in the pile. So instead of 1 place to look, you'll have dozens.
    – Dunk
    Commented Jan 7, 2016 at 20:27
  • Thanks for the lecture on names but I have been developing for 3 decades and pretty much put naming at the top of the list as far as importance goes (in programming). Maybe this class is more than just storage (I didn't look very closely) but I was making the observation that sometimes the 'manager' issue is caused by naming rather than bad design.
    – LegendLength
    Commented Jan 8, 2016 at 5:26
  • Keep calm, guys, no reason to invest so much time and energy in a three year old question where we actually have no idea how the code really looked like.
    – Doc Brown
    Commented Jan 8, 2016 at 7:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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