Are global objects a good idea?

[Leon]

Hi

I am getting back into development after a long time, so my question might be "dump"

I have an object called ImageFetcher. My options are:

• Allow mixed use of imageFetcher-> and ImageFetcher:: (so some classes would receive the object, some would not)
• Send the object to every class that needs it, so allow only the use of imageFetcher->
• Create a global object, accesible by every class, to use with imageFetcher->

I personally think that the global approach is the most "clean". I guess there would be some "safety" issues, so this should be done carefully.

[Christian Ehrlicher]

@Leon said in Are global objects a good idea?:

I personally think that the global approach is the most "clean".

No, global objects a.k.a. singletons are an anti-pattern.

[Leon]

@Christian-Ehrlicher

Thank you! That's exactly what i wanted to hear.

Between the first two then what should i prefer? Is the first also an anti-pattern?

[SGaist]

Hi,

Before answering you need to provide more details.

How many classes need to access it ?
How are they suppose to use it ?
You seem to have static methods, what would they be used for ?

[Leon]

@SGaist

I definitely need to reconsider which methods need to be static.

To my understanding, even if the method is 100 lines, and only one line has a Q_EMIT, then that method shouldn't be static. Is that correct?

[JonB]

@Leon
Only an object/instance can emit a signal. Assuming you mean emit someSignal() that cannot be in a static method. You could have some object emit someObject->someSignal() in a static method, but that is probably not what you have in mind.

[Asperamanca]

@Leon What is imageFetcher supposed to do?

[Leon]

Thank you all for your answers! They have been really helpful

@Asperamanca

I didn't want to dive into the specifics of the class, as i am searching for general design patterns

[Asperamanca]

@Leon Then my answer is: They are usually not a good idea, but there are valid exceptions.