- [Instructor] Before we talk about reactive programming,
let's take another step back
and talk briefly about design patterns.
What is a design pattern?
Who comes up with this?
Why do we care?
When I started out as a junior developer,
I started with relatively small tasks,
maybe updating one part of an application
someone else had written.
As I grew into a senior developer,
I started taking on larger and more complex tasks,
and even started writing my own applications from scratch.
And as many of you know, if our code isn't well-organized
it can get quite messy and confusing.
As a senior developer,
I needed to start thinking about the structure
and architecture of our code,
preferably before I started writing it.
And if I'm going to work with
or lead a team of other developers,
I needed to be able to communicate
about that structure with my team.
On that note, let me introduce the Gang of Four.
Together they wrote a famous book called Design Patterns,
Elements of Reusable Object-Oriented Software.
Although it was published in 1994,
it is still considered an influential book
and remains an important source
for object-oriented design theory and practice.
And without getting too far back into programming history,
I can't mention the Gang of Four
without mentioning Christopher Alexander.
He was originally an architect,
but he was such a visionary that his theories about design
influenced other fields such as software.
He wrote several amazing books back in the '70s,
and he invented pattern-based design,
which led to the Gang of Four's Designs Patterns
20 years later.
Alexander said a pattern describes a problem
which occurs over and over again in our environment,
and then describes the core of the solution to that problem,
in such a way that you can use this solution
a million times over
without ever doing it the same way twice.
So to recap, in the '70s this guy Christopher
came up with the concept of a design pattern.
In the '90s, the Gang of Four took that concept
and created 23 specific design patterns
that are still used today.
If you know these design patterns,
you'll be better prepared
to have high-level discussions with other developers
about the architecture of your application.
Now in all fairness, this book will not talk about wizards
or hobbits on great adventures.
It's more like reading a textbook,
and even better than counting sheep
if you're trying to fall asleep.
That said, if you are or ever want to be a decision-maker
when it comes to designing complex web applications,
I highly recommend you get this book.
Just google Gang of Four Design Patterns.
It's a famous book, so you can't miss it.
We're not going to cover
all 23 design patterns in this course,
we're just going to cover one, the observer pattern.
Wikipedia says the observer pattern
is a software design pattern
in which an object, called the subject,
maintains a list of its dependents, called observers,
and notifies them automatically of any state changes,
usually by calling one of their methods.
What does that mean?
Basically, the observer pattern
works well for an application
that expects real-time updates.
Or you could also call this event-driven design.
So you have an application
centered around events or updates.
You have a one-to-many pattern
with one subject and many observers.
When your subject is updated, it will fire a method,
which will automatically notify all the observers
of state changes,
usually carrying some updated data along with it.
Simply put, just think of the observer pattern
as something centered around events and real-time updates.