Is it acceptable practice to give an object a pointer to "the world"?

I often find myself in situations where objects need to communicate between each other. For example, a button might need to talk to variou开发者_如何学Gos textboxes. Would it be proper to simply construct each widget with a pointer to the container for all of them? Would it be better to give it a pointer to a resource container map where the object can locate another object by string or something? This area has always been very vague to me. I could easily implement everything I want to do if I just constructed objects with pointers to containers of every other object, but that seems wrong. In the case of a widget, would it actually just be more proper if the widget knew nothing about the outside world and instead its action listeners were constructed with resource access?

Thanks

I understand that it is a bad idea but what are some solutions in these situations eg: good design patterns?

Any object should know as little as possible about things outside itself. What you are describing sounds alot like the ani-pattern often referred to as a 'God object'

You get better de-coupling if you use messages/events.

objects with pointers to containers of every other object, but that seems wrong.

And why do you think it is wrong?

Usually you will not just need to send messages but to do something like navigation/enumeration.

For example HTML DOM tree consists of nodes where each node contains [weak] reference to its parent. Without such reference operations like nextSibling() are just impossible.

So answer depends on set of other operations you will want to implement there.

The answer depends on how long the objects might live and how long the pointers might stick around. Anything which might change needs to go through a directory service. If the target's lifetime is short enough, you might even need to have the directory service place a hold on the target.

DON'T DO THAT!

No, seriously, your idea is analogous to the singleton pattern, with the difference that you have just one instance per "name" instead of per type.

You can collect a bunch of bad things about your idea by seeing what's wrong with singletons.

Why would a button in a dialog(?) want to know how many other objects there are in the dialog?

When the button is pressed, it sends a message to its owner. The owner will then have to coordinate the action between the widgets it owns. You don't want to change the code for you OK-button when the dialog gets another listbox, do you?

You could use dependency injection to pass the pointers you need. That way you make the dependencies explicit. http://en.wikipedia.org/wiki/Dependency_injection

This approach gives you a lot of advantages - unit testing is much easier when you don't have global state, god objects and so on. Also when new guy comes to the team, he can see what are the dependencies of a class - you make it explicit in constructor, so no magic like "you must first create this singleton to use that object or it will crash". This approach reduces coupling, thus making reuse easier.

IMO it is not possible to make every class independent of all the others (you ask if it is better when widget does not know anything about outside world). While this removes coupling making code reuse easier it also is very hard to do and leads to lot more coding.

On the other hand it is a bad idea to pursue some ideology "just because" without understanding why. Maybe in your case advantages of OOP are not worth writing additional code. If you can see that you will finish your application much quicker with "god object" then I would say "go for it".

IMO it is not as easy as "never create singletons and god objects". You must decide if additional time spent on passing all the references explicitly pays back in future.

Personally I always choose what is appropriate for program I write. It is not unusual for me to consciously break some OOP rules. Remember there are also other guidelines - I like KISS.