[SOUND] Hello I'm Craig and I'm a developer.

In this workshop we're gonna explore the extremely popular design pattern,

Observer.

We'll explore what makes the pattern so popular and

we'll also walk through the why, the how, and the when you should use it.

First though,

just want to remind you that there are speed controls on the video player.

Make use of those to speed me up or slow me down to your tastes.

Always remember to check the teacher's notes on each video.

I've drop some prerequisites on this one.

So take a moment and

make sure that we're on the same page before we get started here.

And finally, don't forget to hit up the community to discuss these ideas more.

I'm excited to take the time to walk through the Observer pattern with you.

It's a very powerful and commonly used pattern.

It's ability to make code more extensible is what makes it so popular.

So you'll see it used all over the place as a solution.

Now, I guarantee that you've interacted with this pattern already.

It' everywhere.

I mean, you're literally seeing it at play right now.

See the timeline on this video?

The toolbar is observing where you are in this video.

As you progress through this video, it changes, right?

It updates both the number of seconds as well as the rendering of the progress bar.

So in the video example, the video itself represents the master object, or

subject as it's often referred to.

It's the one portion of the one-to-many.

The many side of things, the dependent objects or observers as they're usually

called, those are the number of seconds displayed and the progress bar.

So the subject changes its state and

its observers are notified and update themselves accordingly.

So with that in mind, you can probably think

of a couple other examples where you can interact with this pattern at work today.

Now, for instance, I was just using a spreadsheet.

When I updated the cell with my percentage complete on a project that I'm working on,

the graph changed.

And so did several other fields that were observing that value.

Those other objects were notified by the changes I made in my cells.

Now the Observer pattern is at play in the compound design pattern MVC.

The V in MVC, or view layer, makes heavy use of this pattern.

The view observes the model.

Changes to the model will notify the view.

Now UI libraries like the ones that you've interacted with, like JavaFX or

Android apps, rely heavily on this pattern to display the current state of the model.

Now, this pattern is often referred to as Pub/Sub which is short for

Publish/Subscribe.

Now this might help things stick.

A newspaper is published and delivered to all of it's subscribers, right?

And that makes sense.

You get the paper because you have a subscription, and

it only comes when a new issue is published.

All right, all right, enough analogies.

So let's go take a quick look at the UML so

you can see the suggested implementation.

So if we do a quick search for the Observer pattern,

we'll see here that the first result here is from Wikipedia.

So let's click this.

Let's scroll down to the UML.

I'm going to go ahead I'm going to click this.

It's gonna open it up and I'm gonna zoom in on it.

So we can take a more detailed look here.

Okay, so we see that there's an Observer interface, and

it has a method called notify.

There's several concrete implementations here, right?

So Concrete A and B, and they also implement, have a method called notify.

So there's a little diamond here on a class called subject,

and what that means is there's an aggregation of these observers here and

they're being stored in this observer collection.

And they get added by calling a thing called registerObserver, and

you pass in the observer or unregister to remove it.

And then there is a method called notifyObservers, and

this is the pseudo code here.

Basically it says for each one of these observers, loop through and

call the notify method.

So basically what this is saying is that any object that

implements the observer interface can be notified.

So, now don't worry, you'll get your head wrapped around it here in a bit.

Just remember that this is a suggestion of how to implement the pattern.

There are numerous ways of achieving this pattern in code and

we'll hit them up separately here in a bit.

Now these names aren't required, but they are common.

So you can start to recognize them when you see them.

While we're here, why don't we go get the starter files for application installed?

So in the teacher's notes there's a link to a rebo.

I went ahead and copied that and pasted it.

Here we are on GitHub.

I'm gonna choose clone or download, I'm gonna grab the URL here for SSH, and

I'm gonna pop over to my InteliJ, which you'll see is running 2016.2.1.

And I'm gonna check out from version control, use GitHub,

I'm gonna put in the password for this.

So I'm gonna come here and I'm going to paste in.

And want to choose clone.

And it says would you like to open?

I'm going to say yes.

It says it's an unlinked Gradle project.

I'm gonna say go ahead and import the Gradle project.

And I'm gonna click it again.

And just click all the defaults here, okay.

Okay, so I've built this was several different modules where

we can break up the different use cases that we're going to do.

So go ahead and just leave all of those checked by default and click OK.

When you take a look here under Project, you can see that the different ones here

are in bold are the modules that we'll be looking at here just a bit.

So now that we've seen it have a pretty basic understanding,

what do you say we put it into practice?

This pattern and its usage has evolved along with Java.

I think a good approach is to walk through a few of the iterations

since you'll encounter them in your journeys.

We'll discuss the pros and cons of each approach.

Let's start with the original implementation.

It's been around since version 1.1.

So let's dust it off and dive into it next.