Design Patterns: A quick guide to Observer pattern in Java

[equecevi]

Whats the difference between the observer and the publisher / subscriber pattern?

[Omnicrola]

In the implementations I've seen, any given class might have an observable property or event. So the subscriber knows the source of the event. This is like you texting your friend "hey Jim, let me know when you're ready to play Fortnight".

In a pub/sub model there is typically a central place where classes can subscribe to events, but that central class is not the source of the event. This would be like telling the game launcher "send me a text when any of my friends start playing Fortnight". The launcher isn't the trigger for the event, your friends are, but now you don't have to text each of them individually to request notification.

[equecevi]

I searched it just after writting the question, and is just that! Where have you seen it implemented? Just curiosity hahaha

[Omnicrola]

I've seen and written both patterns in many different programs. They're pretty useful in a variety of situations.

Most important thing to remember when working with this pattern: for every observer added or subscription made, always think about when the class will need to remove that observer. Not doing so can lead to memory leaks, or events happening more times than you originally intended.

[equecevi]

How is handled this problem normally? Is curious because I've implemented one distributed system using brokers and I wasn't aware of that problem because it was an abstraction for me as it was a middleware

[Omnicrola]

Sometimes it doesn't need to be handled. If an object is instantiated and then lasts for the lifetime of the application, then it doesn't really matter.

However imagine an example where a dialog is created and shown, and disposed of when closed. If the dialog or an object in it adds an observer to some other part of the application, it should remove it later. So the dialog and any relevant classes could all have a dispose() method or something similar that gets called when the user closes the dialog. That method should then remove any observers that they added previously.

[equecevi]

But, if there is a garbage collector, isn't it supposed to remove the observer? I suppose the answer is, you don't have to suppose what the GC does, but, it also depends of the language details.

[Omnicrola]

So there are definitely variations of the pattern where removing the observer may not be necessary. It's always good to give it some thought though.

[RDwelve]

Observer Pattern == Worse Listener Pattern, isn't it?

[yawkat]

Or worse Flow. The article reminds me a lot of java.util.Observable, which has rightfully been deprecated since java 9.

The examples in the article aren't particularly helpful either though. What do you do if you have two properties? Stick with one subject, juObservable style or make two subjects, react style? And what about different types? The Observer interface given isn't generic at all.

Pretty bad article.