What do you understand by an observer?

According to the control theory, the state observer (state estimator) is known as the term that gives the measures of the internal state of any particular absolute system. The state observer uses the input as well as output of the system for measuring the internal state. It is standard computer-implemented and delivers the basis for numerous practical applications.

In order to resolve concerns related to control theory, understanding the system state is crucial, but in most practical situations, direct observation cannot estimate the system's physical state. Rather, system outputs help to observe the indirect effects of the internal state. The example of vehicles in a tunnel is considered: the rates and velocities at entry and exit of the tunnel are easily observed, but you can only estimate their actual state inside the tunnel. When the system is observable, it is conceivable to fully reconstruct the system state from its output measures using the state observer.

What is observer pattern?

An observer pattern can be described as the pattern related to software design that includes an object, subject, keeps a list of its reliance, named observers. It also informs them about state changes, usually by calling one of their methods.

The observer pattern is primarily employed for executing distributed event operating systems in software named "event-driven". The subject in the system is designated as "stream of events" or "stream source of events," whereas, the observers are called "sinks of events." The stream nomenclature indicates to a physical structure in which the observers are physically separated, and they don't have any authority on the ejected events from the source. So, the observer pattern then completely fits all methods where data comes from input that is not available to the control processing unit (CPU) at startup but rather arrives "at random" (HTTP requests, GPIO data, user input from keyboard/mouse/…, distributed databases and blockchains, …). Modern programming languages largely include built-in "events" that creates the observer-pattern components. Also, listening for events in background threads are used by some of the "observer" implementations, whereas various others hold up on mechanisms given by the kernel.

Applying the pattern

An observer design pattern is appropriate for distributed push-based notifications because it supports the partition of two separate parts or application layers, like a data source and user interface. This pattern is applied in most cases where a provider operates callbacks to supply its clients with current information.

Implementing the pattern requires that you provide the following:

A provider is expressed as the object that transmits notifications to observers. The provider is a class or structure that implements the IObservable interface. The provider needs to execute the single method, IObservable. Subscribe, which is called by observers that desire to obtain information from the provider.

An observer is an object that acquires notifications from a provider. An observer is also a structure that executes the IObserver interface. The three methods called by the provider should be implemented by the observer.

IObserver<T>.OnNext, which supplies the observer with new or current information.

IObserver<T>.OnError, which informs the observer that an error has occurred.

IObserver<T>.OnCompleted, which indicates that the provider has finished sending notifications.

The provider contains an object named System.Collections.Generic.List object to maintain references to the IObserver implementations which have subscribed to notifications. The storage container allows the provider to manage zero to an unlimited number of observers. The order in which observers obtain notifications is not defined because the provider is open to utilising any method to determine the order.

The IDisposable implementation helps the provider to release observers when notification is complete. Observers receive a reference to the IDisposable performance from the subscribe method, which can also call the IDisposable. Dispose of the method to unsubscribe before the provider has finished sending notifications.

An object includes the data delivered by the provider to its observers. This object type relates to the generic type parameter of the IObservable and IObserver interfaces. Even though this object can be similar to the IObservable implementation, it is commonly different.

What problems can the observer design pattern solve?

The observer pattern addresses the following problems:

Among objects, the one-to-many dependence must be specified without tightly coupling the objects. It is required to ensure that the open-ended number of dependent objects gets updated if one object varies state. This is also conceivable that one object can inform an open-ended number of other objects.

The one-to-many dependency can be expressed by defining one object, which updates the state of dependent objects instantly is obstinate due to coupling the subject with the dependent object. Nonetheless, it can create sense from an implementation point of view or if the object implementation is tightly coupled. It is challenging to implement tightly coupled objects and tough to reuse because they refer to many various objects with different interfaces. In other systems, tightly coupled objects are better since the compiler will detect errors at compile-time and optimize the code at the CPU instruction level.

Strong vs weak reference

The memory leaks caused by the observer pattern is referred to as lapsed listener problem. This is due to the basic implementation, which needs explicit registration and deregistration. Afterwards, the subject carries strong references to the observers, preserving them active. This can be controlled by the subject maintaining weak references to the observers.

Structure

The subject expresses the core, whereas the observer indicates the variable abstraction. The variable could be a user interface, optional or dependent. The subject is used to stimulate the observer object, and if required, each observer can call back to the subject.

Checklist

• Distinguish among the independent functionality as well as the dependent functionality.
• On utilising a subject abstraction, provide a sample of the independent functionality.
• On utilising a observer hierarchy, provide a sample of the dependent functionality.
• The subject is coupled to the base class of the observer.
• The number and kind of observers are configured by the client.
• Observers register themselves with the subject.
• For all registered observers, the subject broadcasts events.
• The subject can "push" the data towards the observers. Also, the observers can "pull" the essential required information from the subject.

Common Mistakes

Students often get confused between the core functionality and the optional functionality. Remember that the core is an independent functionality, which should be modeled with a subject abstraction. On the other hand, the optional functionality is the dependent one, which is modeled with an observer hierarchy.

Context and Applications

This topic is significant in both graduate and postgraduate courses, especially for:

• Bachelor of Technology in Mechanical Engineering
• Bachelor of Technology in Computer Sciences
• Master of Technology in Computer Sciences

Related Concepts

• Design parameters
• Logical algorithm
• Logic controller

Practice Problems

Q1. A system that utilizes the measures of the input and output of the actual system, is called ________.

1. State observer
2. Subject observer
3. Adapter
4. Prototype

Correct Option: (a)

Explanation: The state observer is described as the system that measures the input and output of a certain system and evaluates the system's internal state.

Q2. Which of the following options is false for the observer design pattern?

1. Object construction is required
2. Change notifications are entailed
3. There is a one-to-many relationship
4. This is a behavioural pattern

Correct Option: (a)

Explanation: The observer design pattern is applied if a one-to-many connection occurs among the object. Also, object construction is not essentially needed for the observer pattern.

Q3. Which phase of the system development is concerned with determining the system feasibility?

1. Conception
2. Construction
3. Design
4. Initiation

Correct Option: (d)

Explanation: System initiation or system planning is a phase in the data system life cycle. It includes documentation of the system goals and the process utilized to create and implement a technical solution to meet those goals.

Q4. Consider the correct option about the flyweight pattern:

1. Decreases the quantity of objects produced
2. Increases the memory footprint
3. All of the above
4. None of the above

Correct Option: (a)

Explanation: The flyweight pattern can be represented as the type of pattern which is applied in order to decrease the quantity of objects constructed as well as lessen the memory footprint.

Q5. Which of the following options is related to constructing a chain of receiver objects?

1. Proxy pattern
2. Command pattern
3. Interpreter pattern
4. Chain of responsibility pattern

Correct Option: (d)

Explanation: The chain of responsibility pattern is involved in various software techniques for accomplishing the loosely coupled system. Also, the chain of acquiring objects for any particular request is constructed by the chain of responsibility pattern.