Skip to content

Instantly share code, notes, and snippets.

@avdi
Created October 5, 2012 20:38
Show Gist options
  • Save avdi/3842243 to your computer and use it in GitHub Desktop.
Save avdi/3842243 to your computer and use it in GitHub Desktop.
Observer pattern terminology

When it comes to the Observer pattern, there are a number of related, overlapping terms used by different codebases. Off the top of my head:

  • Observer/Observable/Subject
  • Listener/Listenable
  • Event/Event source/Event sink/Event handler
  • Hook/Callback
  • Subscriber/Subscribable
  • "Firing" vs. "Triggering" vs "Notifying" vs "Executing"

Which of these do consider to be synonymous?

Of terms that are synonymous, which do you prefer to use in your programs?

Of terms that are not synonymous, what semantic differences do the different terms imply to you?

@upstarter
Copy link

Curious if subscriber/subscribable fits here as well?

@avdi
Copy link
Author

avdi commented Oct 5, 2012

@rubycoder1 yes! Added.

@davidjbeveridge
Copy link

Does Command apply here?

@avdi
Copy link
Author

avdi commented Oct 5, 2012

@davidjbeveridge no, I'd say not.

@mattwynne
Copy link

'Observable' is called subject in the GOF pattern.

@mattwynne
Copy link

I think hooks and callbacks are different because you're observing individual messages (using a Proc), whereas observers / subscribers seem to mean an object that understands a richer protocol.

@gicappa
Copy link

gicappa commented Oct 5, 2012

Brainstorming:

  • Observer and Listener to me are synonymous in the behaviour but you listen for an event and observe an object.
  • So there is a more strict semantic connection between the "subject object" and the "observer object" because all the concrete observers share the same type while the listener of an event can be very diverse.
  • An event in general recalls me an async concept that decouple the time of execution of a procedural flow and can be listened and so handled.
  • But Event Source reminds me the DDD Event Sourcing pattern that is very specific way of handling messages between two different bounded contexts.
  • A callback is generated by a method call but it doesn't specify a relationship of two or more objects. It just happens when a message is sent.
  • Publishing subscribing mechanism shifts the accent more on passing data asynchronously more than sending messaging decoupling the time axis.
  • "Firing" an event will "Trigger" a listener that could "Notify" an observer that will "Execute" a query :) Jokes apart I think execute is the only not time decoupled verb here.

Does something I said makes sense to anyone? :D

  • Hook/Callback is a just function that is triggered by some specific message arriving on an object (a method call). So the difference with the listener/object is that the callback is just involving the object that defines it

@avdi
Copy link
Author

avdi commented Oct 5, 2012

@mattwynne thanks! Updated.

@gicappa
Copy link

gicappa commented Oct 5, 2012

The very last point is a typo. Sorry.

@gicappa
Copy link

gicappa commented Oct 6, 2012

If i did - I didn't mean to stop the conv flow (!) and I'm very intersted in understanding what do you think about my brain dump and confront it with different opinions! So I'll keep on observing this subject or subscribing this publication as you wish :-)

@airblade
Copy link

airblade commented Oct 6, 2012

"Firing" vs. "Triggering" vs "Notifying" vs "Executing"

The first thing that springs to mind when I read these is firing an event, triggering a state change or transition in a state machine, notifying a listener, and executing a method.

I've also seen codebases talk in terms of emitting events.

I tend to think an object would 'listen' to events generated (to use a neutral word) by another object, but 'subscribe' to a persistent message queue or topic (where "message" is not the OO kind of message, but the message bus kind of message).

@kevinrutherford
Copy link

Observer and Listener seem closely coupled with the source, compared to Publish/Subscribe and Notify, which both feel quite decoupled from the source (of events/notifications). So I will ATTACH a Listener directly to an object, but Subscribe to events/notifications from who-knows-where.

@gicappa
Copy link

gicappa commented Oct 6, 2012

@kevinrutherford +1 this is a good point: in general you can publish/subscribe to a "topic/queue/board" that is a more general concept than listen/observer an object.

@josemotanet
Copy link

I've seen pub/sub as in — publish / subscribe — somewhere when developing Javascript a time ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment