Intersection section of course we're going to take a look at the observer Design Patterns so why would
you want to use an observer.
Well sometimes as your system is running you need to get information about when certain things happen
you basically want one component to be informed about something happening in the other component and
that can be a lot of things.
It can be for example that a field changes to a particular value or you want to be informed when the
object does a particular thing all you want to be informed when some external event occurs.
For example.
So whatever the case may be we want to be able to listen to these events and to be notified when they
actually occur.
Now actually when I'm using the word event this is a terminology which is one of the two possible terminologies
which are used in C++ programming language.
So sometimes what we say is we talk about events.
And whenever you want to listen to the event whoever is indicating they're interested in an event is
called the subscribers that you subscribe to a particular event and this is the kind of terminology
that's being used in other programming languages such as C-Sharp for example.
But there is also a parallel terminology which uses the terms signal and slot to indicate pretty much
the same thing.
So instead of an event you have something called a signal and typically you can think of it like a like
a traffic light signal for example something that basically changes and it gives you an indication that
its changed.
And then you have a slot and the slot is basically that location which actually handles the signal when
it's actually fired.
So the slot would be for example it could be a lambda function that you've provided to handle that particular
signal firing.
So these two terminologies are both valid when we talk about let's say the boost signals library we're
going to talk about signals and slots whereas in the general case I would prefer to talk about events
and subscribers to those events.
So the observed design pattern is well it's split into two parts in actual fact so we have the observer
itself.
Now the observer is the object which wishes to be informed about something happening somewhere in the
system.
It wants to observe a different parts of the system and get notifications on it and the entity that's
actually generating these notifications or these events is called an observable.
So we're going to implement both of these as part of the section of the course.
All right so let's try to summarize the things that we've learned about the observed Design Patterns
so typically we saw that the observed design pattern has two participants.
You need two participants to actually have an observable scenario so you have the observer which actually.