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

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am implementing a controller class to manage a view. I have a file uploader class, Grabber, which could communicate in one of 2 ways:

1) Offer some kind of notification event to the controller on upload start and finish

2) Provide a property on Grabber that indicates true or false if upload has completed

I am concerned that with option 2) I am introducing a dependency between the controller and the Grabber.

What is the better design here?

share|improve this question
It could be a reaction to the phrasing not clearly expressing your question. I'll edit to assist. – Gary Rowe May 31 '12 at 21:00
up vote 6 down vote accepted

yes it is a good pattern, in fact it is the basis of most patterns and is called loose coupling

this will make it easier in general should you need to modify the Grabbing class in the future: for example when you want to notify the viewcontroller of an error that occured during uploading, with the events you define a error event to pass on to the view controller, while otherwise you would need to have a second property that only holds a meaningful value when grabbing.isDone() returns true.

also in this case it prevents the busy loop pattern of repeatedly checking the property to see if it changes before moving on

share|improve this answer

This appears to be a classic case of the Observer pattern

Therefore, I would suggest that you implement a GrabEvent that contains state to indicate if it is a start, finish or error event. The Grabber then issues these GrabberEvent instances to anyone who has registered as a GrabberListener (or GrabberObserver).

However, you must make sure that the listeners are decoupled from the event provider (Grabber) thread. If not, your Grabber event handler will end up calling into the GrabberListener instances and updaing their state in a separate thread which could introduce inconsistencies and poor performance if the implementations of those listeners are outside of your control.

In Java, a good way to decouple consumers from providers is to use a BlockingQueue so that each end of the queue runs in its own thread.

share|improve this answer
Actually it is called Observer pattern in GoF Design Patterns. Listener is called Observer; and the object where the state is broadcasted from is called Observable. Some language frameworks (such as C# and Java) have corresponding classes for this in their class libraries. – Spoike Jun 1 '12 at 11:07
@Spoike Oops. Good call out - will edit accordingly. – Gary Rowe Jun 1 '12 at 11:51
A lot of examples actually call the Observers as Subscribers mostly because it is easier to think in those terms as a metaphor when you implement this pattern. They need to "subscribe" to the data that they want, much like you can subscribe to a newspaper or a magazine. – Spoike Jun 1 '12 at 13:16

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.