There are many aspects that must be taken into account when programming software : the final product, for example, must not only have the desired functions, but its source code must also be readable and understandable . Naturally, to achieve this, the least possible effort must be invested, especially if programs or parts of them are developed with recurring functions or elements. The so-called GoF (Gang of Four) patterns offer for this purpose a range of predefined solutions to various typical problems in software design ..
Like other popular patterns such as the Visitor pattern and the Singleton pattern, the so-called Observer pattern is also part of this collection of practical design patterns that make everyday life so easy for programmers . We tell you what the Observer pattern consists of (including a graphical representation in UML) and what advantages and disadvantages it presents.
The Observer Design Pattern, Observer Pattern, or Observer Pattern is one of the most popular software design patterns . This tool offers the possibility of defining a one-to-one dependency between two or more objects to transmit all the changes of a specific object in the simplest and fastest way possible. To achieve this, any other object can be registered on an (observed) object, which will function as an observer. The first object, also called the subject , informs registered observers each time it is modified..
As we've already mentioned, the Observer pattern is one of the GoF patterns included in the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software . The more than 20 design solutions described in this publication continue to play an important role in the conceptualization and development of computer applications today.
The Observer pattern works with two types of actors: on the one hand, the subject , that is, the object whose state wants to be monitored in the long term. On the other hand, there are the observing objects , which have to be informed of any change in the subject..
Generally, a subject has multiple observers assigned to it, but in principle, the Observer pattern can also be applied with a single observer object.
Without the Observer pattern, observers objects would have to apply to the subject regularly send them updates on their status ( Updates status ). Each of these requests would take computation time and would also require certain hardware resources . The Observer pattern is based on the idea of centralizing the task of reporting in the hands of the subject. To achieve this, there is a list on which observers can register. In case of modification, the subject informs them one after another, without the need for the observers to actively request it. If an observer no longer needs automatic updates later on, they can simply unsubscribe from the list.
Two different methods can be applied to inform each of the observers. With the push method , the subject indicates directly in his message what changes have occurred. This method can cause problems if information is transmitted that the observer is not able to process. The pull method , on the other hand, does not present this problem: with it, the subject only transmits the information that changes have occurred. If observers want to know what the changes are, they have to request the updated status by calling a special method.
The mode of operation and use of design patterns, such as the Observer pattern, is often difficult for those unfamiliar with the subject to understand. To facilitate understanding, it may be helpful to look at a graphical representation of the design pattern . The extended modeling language UML (Unified Modeling Language) is especially suitable for this purpose, since it allows to describe the relationships in an understandable and intuitive way, both for the users of the application and for the experts. Therefore, we have chosen UML as the modeling language to provide the following abstract representation of the Observer pattern.
The Observer pattern can be the appropriate solution to many design problems. Its greatest advantage is the high degree of independence between the observed object (subject) and the observing objects interested in the current state of the subject. The observed object does not require any type of information about the observers, since the interaction is carried out independently through the interface of the observers, who receive updates automatically . This way, requests are no longer made in vain (when the subject has not been modified since the last request).
However, automatic updates by the subject to all registered observers is not always an advantage, as the transmitted change information may be irrelevant to certain observers. This process is inconvenient especially when the number of registered observers is very high, since a lot of computing time is wasted. Another disadvantage of the Observer pattern is that the subject's source code often does not reveal which observers are being reported.
The Observer design pattern is mostly implemented in component-based applications whose state,
Some of the typical applications of this pattern are GUIs (graphical user interfaces), which act as a communication interface easy to use between users and the program. Every time data is modified, it must be updated in all GUI components. This situation is perfect for the application of the subject-observer structure of the Observer pattern. Even programs that work with data sets in visual format (be they classic tables or graphical diagrams) can benefit from the structure of this design pattern.
As far as the programming language is concerned , the Observer pattern does not, in principle, carry any specific limitations. The only requirement is that the object-oriented paradigm be compatible with the pattern. Some of the most widely used languages to implement the Observer pattern are C #, C ++, Java, JavaScript, Python, and PHP.
There can be big differences in the implementation mode of the Observer pattern depending on the programming language used. However, the basic concept of the implementation is always the same: access to a particular object (or its state) is made available to many other objects . The Observer pattern tutorial from javabeginners.de offers a very representative example of what happens in practice and can be very useful to understand this concept.
In the example we want to show a text published by the sender in the text fields of several receivers . To do this, the subjectclass (e misor , subject ) adds the addObserver () method to the observableclass . Thus, receptors can be added . In addition, the setChanged () method is introduced , which registers changes in the subject and makes a call to notifyObservers () in case of changes, thus informing all observers.
class emisor extends Observable { public emisor(){ this.addObserver(new receptores_1()); this.addObserver(new receptores_2()); tell("Text"); } public void tell(String info){ if(countObservers()>0){ setChanged(); notifyObservers(info); } } }
Observers also need an implementation of the observation interface, including the udpate () method and two arguments: the observed object and the change in the form of an object instance ( ConcreteSubject ).
class receptores extends JFrame implements Observer{ private JTextField field; public receptores (){ field1 = new JTextField("a"); add(field); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setSize(300, 50); setVisible(true); } public void update(Observable o, Object arg) { field.setText((String) arg); } }