When it comes to JavaScript design, the Observer pattern also known as the subscriber pattern, is a developmental design pattern that involves a object, which is also known as subject authorizing a list of its dependent which are called observers or subscribers. What this specific pattern does is give objects the ability to distribute information to one another without having explicit knowledge of each other. The instance of Observer Patterns are very popular when being put to use by developers, as they are used in numerous domains across software engineering. It’s common for them to be present in event driven systems, MVC’s and graphical user interfaces.
Understanding the livelihood of Observer Patterns involves being aware that two critical components lie at the heart, being the Subject and the Observer. The subject is is the operation being spectated or examined, which handles a list of observers and enable methods to add, remove and notify them. Observers on the other hand deals with receiving updates from the subject, also while including a implemented method that notifies changes to the subject condition. This promotes decoupling, when is when the observers are not squeezed with the objects, they having breathing room to be added or removed, without affecting other observers or the subject.
It’s important to expand more on observers, as it can sound similar to what a subject does. When the state of a subject changes, in any way, shape or form, it informs all observers, allowing them to process the information.
Observers have a implemented method, that allows them to retrieve and handle this incoming information from the Subject. This is known as the ‘update()’ method, and it enables the action that observer absorbs in response, while making needed changes in the subject.
Observers play a essential part in forging the one-to-many relationship between the subject and all the observer content. They implement loose data transferring between objects, due to the subject not needing to have direct knowledge of the observers.
So in simple terms, subscribers are the objects that enable the receiving of notifications from the subject and create functioning methods that handle these changes when they present themselves. Basically being the connection of communication between all objects, without them having direct access to each other.
Subjects naturally have data that will usually change over time. When the state of the subject changes, all the observers we spoke about servers are informed, by invoking a specific callback on each observer.
The Observer Pattern declarations can be created with the class keyword inside of JavaScript. Inside of the class, a construction function is created also, which then the observers array is created. Outside of the constructor, the methods of the Subject are then declared. These being the methods that deal with the observers. First there is a method for adding observers, which adds the brought up data into the observers array. There’s also the method for removing the observers. Last but not least, there is the method for notifying the observers of any changed that have been brought up in the subject at all.
The whole idea for Observe patterns is in it’s name, the changes are being observed, and taking note of any changes inside of objects, down to the smallest thing that was altered.
Observe patterns are all about communicating, while still allowing the data in difrerence places to be stored and flexible. However, the fact that there can be so many moving parts at any instance when it comes to dealing with objects, it’s important to not have too much information all clunked up together. That’s why the data being loosely stored plays a root, in all of the methods having their own declaration, instead of everything being bunch up in one small part together. Let’s say we had a new class instance that dealt with a button being clicked. The moment we clicked that button, let’s say we have an observer that outputs the console log of saying “this button has been clicked”. The moment that button is clicked, it is transferred to the addObserver() method, which in consequence pushes that observer to the observe array, that’s in the construction array of the class. That data is stored in that array, and then notified.
Another good example would be if we had a teacher dealing with student grade performances in a classroom. The final grade would be the subject, because every new performance that the student or students result in, would have be information thaqt needs to be stored, and immediately resulting in a change the final data. Whether their final grade raises or lowers, it’ll all be beacuse of their input. The teacher communicating with the grade book would be the communication of all observers. Adding grade, removing grades, applying fixes or corrections. All of these changes, no matter how big or small would be observed and have a effect on the final output.
https://www.tutorialspoint.com/design_pattern/observer_pattern.htm
https://www.youtube.com/watch?v=wiQdrH2YpT4
https://www.geeksforgeeks.org/observer-method-javascript-design-pattern/
https://javascriptpatterns.vercel.app/patterns/design-patterns/observer-pattern
https://www.youtube.com/watch?v=PldXoGemkyk&pp=ygUaamF2YXNjcmlwdCBvYnNlcnZlIHBhdHRlcm4%3D
Top comments (1)
A code sample would have demonstrated this common design principle well. I had tried this sometime back in Java, though. See my post: Java PropertyChangeListener as an Observer