title: Observer: Implement with pattern (subject & observer) or inter-thread communication (wait & notify)
body: <p>I usually use the <a href="http://en.wikipedia.org/wiki/Observer_pattern" rel="nofollow">Observer</a> <em>pattern</em>, my colleague at work though has implemented an Observer using Thread intercommunication (using <code>wait</code> and <code>notify</code>/<code>notifyAll</code>).</p>
  
  <p><strong>Should I implement my observers using the pattern or inter-Thread-communication using wait and notify? Are there any good reasons to avoid one approach and always use the other?</strong></p>
  
  <p>I've always gone with the first one, using the pattern, out of convention, and because it seems more expressive (involved identifiers are a good way to express and understand what is communicated and how).</p>
  
  <p>EDIT:</p>
  
  <p>I'm using the pattern in a Swing GUI, he's using the inter-thread solution in an Android application.</p>
  
  <p>In his solution one thread generates data and  then calls <code>notify</code>, to wake up another thread that paints the generated data and calls <code>wait</code> after every paint.</p>
  
  <p>His argument for the <code>wait</code>/<code>notify</code> solution is that it creates less threads and even several concurrent calls to <code>notify</code> will cause only 1 paint event, whereas an observer-based solution would call a repaint with every call. He says it's just another valid approach, but doesn't claim he's done it for performance reasons.</p>
  
  <p>My argument is that I would express the communication among objects on the OO design level rather than use a language-specific feature that makes the communication almost invisible. Also, low-level thread communication is hard to master, might be hard to understand by other readers, and should rather be implemented on a higher level, i. e. using a <code>CyclicBarrier</code>. I don't have any sound arguments for one or the other solution, but I was wondering if there are any sound arguments for either one or the other approach (i. e. <em>"This-and-that can happen, if you use this approach, whereas in the other one that's not possible."</em>).</p>