Talk:Observer pattern

message: Libraries and frameworks exist for JavaScript to utilize the observer pattern, but some like RxJS are incorrectly associated with the Observer pattern. RxJS is only helping as a wrapper for upstream events like DOM click events or promises. But, the observer pattern definition that originated from the Gangs of Four is critically about the mutation of data state that requires a "Subject"https://www.journaldev.com/1739/observer-design-pattern-in-java; RxJS cannot observe the modification of a "Subject" Javascript variable or object. 
The bulk of this wiki article is inconsistent with the original definitionhttps://www.dofactory.com/net/observer-design-pattern that requires an object rather than an event source. The reader should be aware that the current article currently duplicates the idea of an Event Stream.  — Preceding unsigned comment added by Merarischroeder (talk • contribs) 01:11, 24 January 2021 (UTC)
thread_title:  The whole basis of this article is currently incorrect 

message: The example implementation in C++ is good, but it contains a small flaw: if an additional concrete observer is added that inherits from ObserverBoardInterface, but NOT from DisplayBoardInterface (or vice versa), the code will crash. One way to address this would be to add a new member variable to ParaWeatherData like so:
   list<DisplayBoardInterface*> m_disp;
along with these new functions:
    void registerdisp(DisplayBoardInterface* disp)
    {
        m_disp.push_back(disp);
    } 
    void removedisp(DisplayBoardInterface* disp)
    {
        m_disp.remove(disp);
    }
Then change the function notifyOb() to iterate through each list separately, calling the appropriate fns in each case. Of course, the constructors in the concrete observer classes would need to be updated as well. 
I'm new to this, so if there is a simpler adjustment that would work, I'd love to hear it. Kmote (talk) 22:29, 15 December 2008 (UTC)
thread_title:  Implementation flaw in C++ 

message: Short comment on the image: Since the subject class has to notify several observers, an asterix is missing in the UML diagram in order to indicate multiplicity! —The preceding unsigned comment was added by 89.49.166.151 (talk • contribs) 11:24, February 18, 2006  (UTC)
Do you really want a picture of Asterix there? Or perhaps an asterisk? :) —The preceding unsigned comment was added by 199.172.169.17 (talk • contribs) 09:36, April 3, 2006  (UTC)
The image is not valid UML: The line connecting the code comment to the notify method is missing a circle on the end. Further, while it is grammatical to say that a subject is composed of its observers, it's a moronic thing to say. I'm referring to the line connecting the observer  with the subject. That should be a simple association. Multiplicities on that line would help. The class boxes contain an empty attribute field, which is superfluous. 130.92.9.58 (talk) 11:27, 22 July 2010 (UTC)
thread_title:  UML diagram 

message: I think the article needs a section about possible deadlocks (two or more objects observing each other and updating in an infinite loop), and possible solutions to this deadlock problem. 80.57.251.230 (talk) 22:27, 2 December 2008 (UTC)
replies: text: Wouldn't that be more of a livelock, actually? –Johannes Rössel (talk) 06:16, 13 May 2009 (UTC)
thread_title:  needs a section on deadlocks? 

message: "... event which may be raised by the observed object (the subject). (The object which may raise an event generally maintains a collection of the observers.)" Isn't the sentence "An object listens for a subject" aganst of language grammar rules? Why not to exploint the conventional terminology: event source/publisher fires an event to event listeners/susbcribers or invokes them to observe the event? --Javalenok 11:38, 10 October 2006 (UTC)
thread_title:  subject vs. object 

message: The UML diagram should use the naming convention from GOF. Specifically the notify() method in the **Subject** looping through its Observers and calling the **update()** method in those Observers. Having a notify() method in the Observer is confusing, it should be called update(). —The preceding unsigned comment was added by 68.175.22.82 (talk) 19:31, 8 December 2006 (UTC)
thread_title:  GOF consistency 

message: Before we get to the diagram somebody mentioned above, sadly deleted now. I remember basing my code on it and it was exact and correct UML2 notation - the person who put it in originally was correct.  First a few very strong words based on fact and history:
GoF desperately needs to be updated - but that is no excuse. 
With reference to UML in GoF and the collection of above people strongly agreeing with each other! First there is NO UML IN Gang of Four - NO NOT ANY! The book Design Patterns: Elements of Reusable Object-Oriented Software, Enrich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, 1995" predates UMLs first release.  The diagrams are all in OMT Object Modeling Technique which is now 11 years out of date and UML version 1 is NOT MENTIONED AT ALL IN THAT BOOK and so is not used for the diagrams.  Software architects are now using UML version 2!   This does not invalidate that bible, and it was intended to be read by clever design people who are also capable of hatching their very own patterns (see the book Pattern Hatching by John Vlissides one of the gang of four himself). UML was based on a form of Rumbaugh OMT and Booch Method as well as many other types of representation techniques, so reading GoF as part of a UML course confuses the uneducated easily.  UML pre-release as a white paper was however published about that time.    
I noticed with great annoyance that some of the other design pattern wiki entries use the OMT format which can not be entered into Enterprise Architect (for example) because the UML2.0 validation quite rightly rejects them - (the validation is not super strict because UML2 allows flexibility and design creativity of methodology representations ).  I must stress to my critics that Enrich Gamma, Richard Helm, Ralph Johnson, and John Vlissides as well as famous design pioneers like Grady Booch and the prime inventor of OMT James Rumbaugh (retired 18 months ago) all use modern UML2.  Many so called UML articles on the web show GoF diagrams exactly as in their book, box for box and word for word a case of blatant plagiarism - lacking all original effort and design imagination, especially lacking intellectual rigor with regard to UML. 
So yes please go along with the famous Gang of Four but please actually use Unified Modeling Language 2.0 terminology and of course use those authors terminologies too WITHOUT REPUBLISHING THEIR CHAPTERS - best leave out the 11 year old Object Modeling Technique!  Please look up Grady Booch, and Object Modeling Technique then compare to UML.  
If you think that GoF is rigorous UML2 notation as somebody obviously does think (above) then it is best to come back in a few years!  Ask yourself if it is a good idea to update any wiki Design Pattern in this encyclopedia if you are not capable of inventing your own patterns for which there are potentially thousands.  It is just as easy for those people to create anti-patterns - see the entry "anti-patterns".
:OK, GOF didn't use UML. No one said they did but anyway that's sorted. 81.187.215.34 (talk) 23:04, 1 July 2016 (UTC)
thread_title:  Gang of Four Diagrams are NOT UML and they NEVER WERE! 

message: Who invented this design pattern? When?
Answer: Like most patterns they are older than time itself and can be found in atomic physics, quantum mechanics, biological processes, genetics, animal behavior etc.
It is an interesting question because almost all programmers for the last 40 years or more have used design patterns and idioms without realizing it and often they use anti-patterns too which means that the software appears to work but end up full of bugs. Certainly the observer pattern was used by myself in Bell Labs telecommunications long before Gamma et la published their book, we just called it the callback technique. I learned that technique from games programmers that are now mostly dead and some of these chaps predated UNIX. The real answer is strange and mind boggling. 
In MIT, C was used in an object oriented way to write UNIX X-Windows and again this "callback" technique was used in an OOP style in C (not C++) because C++ did not exist. RPC (Remote Procedure Calls) on UNIX existed since the 1970s. 
Reality is however stranger than you can imagine.
The more generic answer is that the observer pattern is not just a computer science pattern at all. Look up design patterns. To prove my point Stroustrup the creator of C++ said that "C++ allows you to model real world problems using higher conceptual levels and to use higher levels ofabstraction or abstract techniques." So these obviously include simple idioms and more abstract design patterns. He used the words "real world" and indeed most if not all patterns exist in the real world outside computer science. The test of this is simple:
If you can simulate the problem on the computer and use the pattern to clearly and beautifully solve the problem and that pattern is reusable for a variety of similar problems - then you have a pattern. A pattern is more than just a simple solution to a problem it must be non-trivial and repeatably applicable with successful results in different environments.
It is important to understand that patterns can be manufactured to solve a specific problem in a specific environment and then can be recognized and reused more formally with names being given to them. These patterns do not need to be computer science patterns and many of them are ordinary complex problems that already have solutions so the patterns are already there and already discovered. GoF gave them names and there are thousands to be discovered. Non Computer Science design patterns have been around for as long as man could design anything and you can computerize these patterns, they were used by the Egyptians to build pyramids over 3000 years ago obviously without computers but with mathematical models and formula.
The observer pattern is not as strange as you think it is, but it is as old as time itself.
You can take it back even further than man. The idea of a biological process, or a genetic process or a group of social animals or insects these also use patterns some much cleverer than the observer pattern. Take a colony of meerkats where there is a division of labour, one animal is the "look out" while the others dig for insects. That look out animal is selected or self selects to be the subject up a tree and the others stay near by as observers. The lookout can spot an eagle, banded cobra or jackal and sound the alarm; even a different alarm, one for each threat; then they all either run to fight the snake or dive for cover underground, depending on the message. It's not hard to fit the observer pattern and other patterns into that?
If you think that is far fetched you can easily simulate that behavior and implement the simulation using the observer pattern and other patterns! You can take the simulation and use it as the framework for a video game.  —Preceding unsigned comment added by Tjclutten (talk • contribs) 09:23, 1 February 2008 (UTC)
thread_title:  History 

message: The C# and Java implementations could both go into one subsection. Perhaps it could start with the pseudocode and then proceed to each implementation like so:
   - Pseudocode
   - Examples
     - C#
     - Java
If someone else agrees I'll make the changes.
--arkul 22:13, 26 August 2007 (UTC)
thread_title:  Implementation refactor 

message: The dictionary should be composed in the Observable class not inherited.
http://wiki3.cosc.canterbury.ac.nz/index.php/Avoid_inheritance_for_implementation  —Preceding unsigned comment added by 125.236.134.253 (talk) 08:20, 3 December 2009 (UTC)
replies: text: Simply add underscores around the init methods and it runs in Python 2.5... I've refactored this a bit. --Mrwojo (talk) 23:28, 2 March 2008 (UTC)
thread_title:  Implementation flaw in Python 

message: The observer's method should NOT be notify() that is totally confusing to new users. Use 'update'. This is really bad.
I disagree, the canonical source for this pattern describes signalling where the observer then queries to get the state. Update would be the incorrect name. Notify or Signal are more suitable. --Merarischroeder (talk) 02:23, 24 January 2021 (UTC)
thread_title:  observer 

message: This implementation broke two general principles of object-oriented design with Java. 
Explanations:   —Preceding unsigned comment added by 132.217.93.123 (talk) 20:29, 7 July 2008 (UTC)
thread_title:  Bad implementation in Java 

message: Shouldn't the Subject class be defined as abstract and the Operate() method moved to it's own class, to have a better encapsulation?
85.127.185.133 19:42, 16 October 2007 (UTC)
thread_title:  C# implementation: abstract Subject 

message: The insanity of this article continues. Whoever is in charge of this article needs to stop. 
It is not attach detach. STOP THE MADNESS. removing observers is not an integral part of the pattern. yes, it should be discussed later on, BUT IS NOT IN THE PRIMARY DEFINITION. READ GOF. WHAT IS YOU PROBLEM?
ADD and NOTIFY -- thats it. Stop inventing your own language and notation. something is seriously deeply wrong with you.  —Preceding unsigned comment added by 38.96.160.34 (talk) 16:14, 21 February 2008 (UTC)
replies: text: No one is in charge of the article. Your vandalism attempts are reverted by different editors. Creating a 'wrong' diagram is not a crime as you keep saying. Try to get some perspective, is it really likely that it's everyone else that's insane? 81.187.215.34 (talk) 22:22, 1 July 2016 (UTC)
thread_title:  Insanity 

message: Im not really clear on why this article is CONSISTENTLY WRONG, but whoever keeps A) making the diagrams, and B) describing it is NOT QUALIFIED to talk on the subject.
OPEN GOF, read about it, and then learn something.  —Preceding unsigned comment added by 38.96.160.34 (talk) 16:17, 21 February 2008 (UTC)
thread_title:  Something is seriously wrong. 

message: I've requested that a diagram be made available for this article. After reading through this page I think it's only fair to remind people that arguing with people on the internet is like competing in the Special Olympics (for want of a better phrase). If you find something incorrect on Wikipedia then by all means change it! Bactoid (talk) 02:11, 3 June 2008 (UTC)
thread_title:  Request for Diagram 

message: considers the Observer pattern and Publish/Subscribe to be the same thing.  Some may consider the Observer object to be one participant (the "broker") in Publish/Subscribe, but that doesn't seem like a good reason to have a separate article. -- Beland (talk) 23:41, 14 May 2009 (UTC)
replies: text: If GoF is the canonical reference, they describe Publish/Subscribe as an alias for Observer. 64.234.88.136 (talk) 15:41, 17 May 2022 (UTC)
thread_title:  Merge with Publish/subscribe 

message: Please see my discussion on Talk:Publish/subscribe#Too_many_articles.3F. Thank you. Quilokos (talk) 00:15, 4 July 2009 (UTC)
thread_title:  Too many articles? 

message: There's nothing in the BASIC part, so I just remove it.  — Preceding unsigned comment added by 115.133.109.229 (talk) 13:53, 28 May 2011 (UTC)
thread_title:  The BASIC part 

message: The java code as of date is using an observer library, but doesn't really explain how the actual pattern is implemented which should be the point of the article. --Popoi (talk) 17:27, 29 November 2012 (UTC)
thread_title:  Java Example 

message: Could somone PLEASE change the Java example code so as not to use a lambda function? This construct is quite new to Java and just makes the code opaque rather than clarifying. If you are writing pedagogical code it surely MUST be the simplest possible, requiring the least prerequisite knowledge! There seems to be no Wikipedia article on the Java lambda function.
Cheers.  — Preceding unsigned comment added by 82.45.163.65 (talk) 20:18, 15 June 2016 (UTC)
replies: text: I've changed it to an inner class instead. 81.187.215.34 (talk) 23:10, 1 July 2016 (UTC)
thread_title:  Lambda function 

message: I have shared the following UML diagrams I have published on Design Patterns Open Online Learning. Your comments are welcomed.
In the above UML class diagram, the Subject class doesn't update the state of Observer1 and Observer2 directly.
Instead, Subject refers to the Observer interface for updating (synchronizing) state (for each o in observers: o.update()), which makes the Subject independent of how (and how many) observers are updated.
The Observer1 and Observer2 classes implement the Observer interface by updating their state (synchronizing their state with subject's state).
The UML sequence diagram
shows the run-time interactions: The Observer1 and Observer2 objects call attach(this) on Subject1 to register themselves. Assuming that the state of Subject1 changes,
Subject1 calls notify() on itself.
notify() in turn calls update() on
the registered  Observer1 and Observer2
objects, which in turn get the changed data (getState()) from Subject1 to update (synchronize) their state.
Vanderjoe (talk) 22:08, 20 August 2017 (UTC)
thread_title:  UML class and sequence diagram 

message: The diagrams show something completely unrelated to the code, the functions prototypes and class relations don't match.  — Preceding unsigned comment added by 85.150.231.254 (talk) 16:22, 13 July 2018 (UTC)
thread_title:  The UML diagrams do not match the code 

message: I agree with the previous comment. I think this article seems to be written from the perspective of reactive streams. More than once I've come across a reactive streams developer who has assumed that RxJava invented the observer pattern. But obviously that's incorrect and this article makes things extremely muddy and confusing for someone just wanting to know what the observer pattern is. Most of it should be deleted IMO, and the rest of it should hew closer to GOF info 77.136.103.17 (talk) 16:34, 13 November 2022 (UTC)
thread_title:  This article is a little off piste