3

I'm trying to learn design patterns, and I have come with the Observer pattern. I think I understand the concept itself, but I don't see when to use it.

I try to explain myself. I work mostly with web applications, so, stateless applications. Normally, the client makes a petition from the browser (for example, update a record). then the operation is completed.

Let us suppose that I want to notify some persons every time a record is updated. It seems to me the perfect scenario for the Observer patter, but when I think of it, it will end something like:

  • user makes petition of update.
  • get all the persons that have to be notified.
  • put all the persons that have to be notified in the observer.
  • make the update. (that also will make the notification for the observer pattern).

but... doing it this way, I have to iterate all the persons that I want to notify twice!

And because its a stateless application, I have to go and get all the persons than needs to be notified every time!

I don't know if the observer pattern is more useful for other types of applications, but I can only think of this pattern in a static form, I mean, making the Observer static.

I know I'm losing something, it's a common and accepted pattern, everyone accept it as a valid solution for this concrete problem. What I am not understanding?

N00b Pr0grammer
  • 4,503
  • 5
  • 32
  • 46
Albert Cortada
  • 737
  • 3
  • 10
  • 25

1 Answers1

3

First, let's straighten out the terminology.

  • Each person who wants to be notified is an Observer.
  • Each type of event which can trigger a notification is an Observable.

Each Observer (person) needs to register itself with the server. It sends a request essentially saying, "I'm interested in foo Observables," which in this case would be, "I'm interested in update events." The server maintains mappings of who is interested in which events.

Every time the server makes an update, it iterates over the mapping of update Observers and sends a notification to each of them.

The advantage is that the server and its Observables have no compile-time knowledge of who the Observers are. Observers are free to register (and unregister) themselves at runtime for any event(s) they are interested in.

jaco0646
  • 15,303
  • 7
  • 59
  • 83
  • I agree with that aproach, and I don't know if this aproach itself it is the observer pattern. I mean, if I save all the persons that want to be registren in a database table, and then recover all that registers, and notify them, it would do the same, with less effort for the programmer and the server. But I don't think that's a observable design pattern.., or it is? – Albert Cortada Feb 26 '16 at 07:25
  • 1
    In the Observer pattern, the programmer doesn't know who the observers are. The observers themselves control what they observe and when; and they are free to change what they observe at any time. – jaco0646 Feb 26 '16 at 14:22
  • I think I get what you mean... is not about performance, but about flexibility... allright, I still don't get it completly, but I think I get some idea to think about. – Albert Cortada Feb 26 '16 at 14:45
  • Correct. Design patterns in general are more about flexibility than performance. – jaco0646 Feb 26 '16 at 14:54