Events & Notifications.

Events, Notifications & Responses.

Events occur when something in Reality happens.

For example:
- When a key is pressed on a keyboard,
- When a certain pattern(s) in electromagnetic radiation are detected by sensor(s),
- When a printer machine malfunctions,

... these all are Events occuring in Reality, events of a certain type, with a given state: additional information & details.


Software parts can handle event occurances, can 'notify' other code parts about events happening ... making hardware-software infrastructure respond to such event occurances somehow.


Also, when objects in memory are created, when objects in memory are destroyed or when objects change state: this also can be a cause of event notification happening, of code parts executing a response.


Registration.

In Object Oriented Programming Languages, often there are objects that observe 'sensors', and notify objects that are registered for notifications.

How to register for event notifications?

... often there's method in a sensor-observing object that handles registrations, other objects call it and give a 'reference' to themselves. Such references are stored in a List or in other data structure, then when event occurs ... a method is called.

/ References are similar to pointers, handles, etc ... and are used in Java Programming Language, for example /.

... for a Code Example: click.


Publish–Subscribe Pattern & Message Broker / Event Bus.

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be.

Such Messages have type, and place in type-hierarchy, in inheritance-tree.

Publishers publish messages of a given type(s), Subscribers subscribe for messages of a given type(s), and message broker / event bus handles messages of all types that fit in its type-hierarchy.

/ there's root message type, every other message is either of that type, or inherits from it, either directly or indirectly /.

Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

This is a nice example of loose class coupling, of reducing dependencies in code.

Code parts - publishers & subscribers - do not have to 'know' about other, these are concerned only with messages they send and/or receive.

This pattern can provide Advantages of Loose Coupling & Scalability.