Okay, before we start on our journey,

I want to remind you of an important piece of advice.

When you're developing you should not start out with a pattern in mind.

Only use patterns when you actually need them.

Now again, this is because using a pattern can cause a lot of overhead, but

when you need it, you'll feel it.

Now, I realize that understanding that feeling when you aren't even sure what it

feels like is probably pretty hard to imagine.

So what I've done is to build up a rather complex multi-threaded application,

to try and help you have that, I need the observer pattern, feeling.

So, here's the scenario.

Let's imagine that we,

you and I, we work for a company that helps provide consultation to restaurants.

We specialize in efficiency.

We suggest different tools and products to make the restaurant's customers flow

in and out in the best possible way.

We've developed some software that helps us demo to our clients,

through simulation, how much better their restaurant could run.

And we've created some simulation software that we use to pitch our ideas.

Running a restaurant efficiently is a difficult problem space.

The better your restaurant performs, the harder it gets to run effectively.

Getting patrons sat down, waited on, fed, and

then cleaning up their tables, becomes a very critical part of your business.

Our first client of the day is having problems with communication between their

staff members.

You know, the tables been cleaned and it's ready.

But the waiter or waitress isn't told about it and patrons are left waiting.

So they're contemplating installing a tablet based dashboard that

we suggested for them.

The dashboard helps keep track of the different tables and

what state they're in.

All the employees, the wait staff and the assistance,

they can look at their dashboard and decide what their next action should be.

Let's take a look at the current implementation.

Okay, so if we open up the restaurant module here.

We'll open that up and then we'll open up src, main, java.

And if we open up down here to the Simulator,

I can show you how this is kicking off.

So this is just the main method here, this simulator and it's got a static void main.

And what I want to show off first is we can create these new tables here,

so there's a table model, so if we open that up and take a look.

We can see that it takes a position number,

which is sort of like a primary key for each one of the tables.

Tables are usually numbered in restaurants and there's also a number of seats,

how many people can sit there.

It also it has a status, let's take a look at what those statuses are.

So, looks like the status is occupied.

So that means that there's people sitting there, they're finished,

they're done eating, they're closing out their bill.

So the server is gonna run the bill.

Needs bussing, that lets the assistant know that the table should be cleaned.

Bussing is the actual act of cleaning it and

then finally we have available when the table's ready.

So if we pop back here to our simulator, let's look,

next up we have a dashboard and that's what we're trying to sell here, right?

So, now let's open that up.

It's pretty basic.

And it shows the whole status of the restaurant in one view.

So what happens is you can call this add table method and

then there's this render method.

And in here, basically we loop through each of the tables that are available and

we group them.

And this is kind of making use of streams and

some Java 8 collector bits that we used to produce a nice looking little report.

It's actually a pretty great use of grouping to create a map

based on the status of the table.

Check the teacher's note for more on this.

So basically, and then it just loops through each one of those states, right?

So each one of status is a loop through and it prints out a pretty little report.

All right. So back to our simulation,

we'll see then that the tables loop through each one of them and

for each of those we call this method reference, add table.

So the dashboard will now have all of the tables that are there.

Okay and then we start building out our servers, so

we have, these are the waiters and the waitresses.

So let's take a look really quick at how we're building these.

So we have an Alice and a Bob server, so let's go ahead and

look at what the server definition is here.

So the server has a couple of public methods,

they can do a lead the table, right?

So when you first meet the people and bring to the table and

then also there's a close out table.

Now one thing that's a little tricky, is that we don't want the task

that the server's performing to block other workers, right?

Now, that's not how things work in real life, right?

Things run at the same time, they run concurrently.

So, definitely the first server can be waiting on a table and

that shouldn't block the other server, right?

You can have a lot of waiters and waitresses in a restaurant.

So this is of course a thing that you can do in code,

cuz obviously you'd need to, right?

It's called concurrency and it's usually done by using threads.

I've employed concurrency here, just a bit,

using an approach called executers and I tried to abstract away

the concept by having performed task take a runnable or a lambda.

So right, there's this perform task here and it takes a runnable.

So you pass it in a lambda and it will do that and

when perform task is happening, the server will be marked as unavailable.

But it won't block other employees right?

So typically what we do is we put in some code to make the thread sleep, so we can

kind of simulate how long something takes so that's what this pass time is here.

Speaking of which.

Server extends an abstract class called Employee,

which provides some common functionality.

Like perform task, for instance.

So perform task is in here, right?

So it's going to say, isAvailable, run the task.

Now they're available.

We also have a static utilities class.

If we open that up, Utilities.

That has this pastTime method and you just pass at the number of seconds and

we'll go ahead and take care of sleeping there.

Thats what thats called, sleeping, as we make times pass.

So, let's pop back over to Employee real quick and

I wanna to show off that there is a method called, announce.

And you basically pass in a message template and

the rest of it gets taken care.

All employees use this to say what they're doing.

This is kind of how we're showing what's happening.

And all employees can also refresh the dashboard, right.

That's what we're building here, so

they'll announce that they're gonna refresh that.

But because we've used an abstract class here we can pretty easily add new

employee types should we need them for whatever simulation.

So in fact, let's see what other types are available.

So if we come in here.

We looked at server already, let's take a look at assistant.

So assistant is the person who is bussing tables and making things all ready for

our next guest.

Now see what happens as they flip the status.

And then the time passes, then they flip the status.

Okay, so let's pop back to our simulator method here.

And let's take a look at the loop.

So things are gonna live about 30 times.

We've found through testing that this is about the right amount of times that you

wanna show a demo to a client.

So we'll do that 30 times.

And the first thing that we're gonna try to do here is get ahold of an available

server.

So we're gonna again use streams.

And streams, we're gonna filter out any server that's available and

we're gonna say find any.

Now it's possible that there is no server that's available, right?

And that's what this optional is about here.

This optional is saying the possibility of an available server exists.

An optional produces a way to protect against nulls.

And so what we can say is we say, isPresent, and that's basically doing

a null check, but if the server is present then we're going to go ahead and

get the server from the optional.

So that's how you access and that's how you protect against it.

And we've done the same thing for the assistant here, so the assistant,

is the assistant available, find any.

And if they are present,

get the assistance, and then refresh the dashboard with them.

Okay, and then what we're gonna do is we're gonna loop through

each of the tables that we have available.

And then we do a switch statement on the status to see each one of these

states that it's in.

And we do the different bits based on who should be working on things.

So if we do have an available server,

we lead them to the table when it's available.

When it's finished, we close out the table, if again, if somebody is available.

And when the table needs bussing, the assistants take care of it.

And then we have a final pass time here in our loop, so

that we don't just bomb the console with output.

We want to make it take a little couple beats, so it'll run about for

thirty seconds.

And finally we want to close up shop on the loops over, right?

So we need to have everybody clock out, that will help this threads that

are running to stop and we're going to shut down the dashboard finally.

All right, you ready to kick this off.

Let's see what happens.

So if you come up here in the Simulator, if you just click

over here this little play button, we're gonna say, Run 'Simulator.main()'.

And here we go, it's starting to kick things off.

So I'm gonna scroll to the top and it's going to keep on filling out.

So what we can see is that Alice has looked at the dashboard.

She's available, so she refreshed it.

She said, she's Alice, she's gonna be your server, follow me to table 1, and

she's got them sat down already.

And then Bob's going to go ahead and he's available, so

he's going to refresh the dashboard.

He's going to say, hi I'll be your server, take me to number 2.

Alice says here's your menus and

then now she's available again she's going to refresh and you'll see that

the tables are now occupied that we can see that from our dashboard.

And bob gives the table the menus.

Bob says follow me to your table.

Alice is now available.

Here's some menus.

And we're showing this to the client.

This what the client is liking to see.

Watching this say that, they're doing a lot of refreshing aren't they?

And Bob says, follow me to your table.

And he says, how come nobody's checked out yet?

So we're still going.

We're gonna get all the tables set.

Bob, we got 5, Charlie's available.

Charlie's refreshing the dashboard.

Here we go.

Four of the tables are finished.

None are available, so now finally We need to get some people in there?

And get the money.

So Bob says, here's your bill for number 1.

That was Alice's table.

Hm?

So now it says finished.

Moving through.

Here comes Charlie.

He's cleaning stuff up and now the table's available again and

we can start the whole process again.

So we're kind of showing off what this dashboard is doing and

the client does notice a couple things right off the bat as a we're showing him.

And he says he doesn't like how much time his staff is refreshing the dashboard,

he thinks that they won't like that.

So I say, is it okay if I take some notes and we'll come back later and

we'll clean this stuff up for you.

So I've got Trello up in here and

I'm gonna start taking some notes on what they said.

So he says that the staff will not like needing to refresh the dashboard,

he says, that is too much.

He also pointed out that the servers seem to be collecting each other's tips.

[LAUGH] And they're definitely not going to like that, right?

So he says, the way that he'd like to run things, or

that servers should be assigned a table and I guess that makes sense.

And the other thing that he notices is there seems to be a priority

towards available tables versus people who have already been sitting there.

So, he does not like that.

He says, prioritization seems to favor availability.

And not the guests that are waiting for their check, he said,

we need to remember that guests that are there occupying the tables.

We need to get their bills turned around quicker, which is true we saw that right?

And other than that he loves this and he's wondering if there's something else that

we can offer that helps keep guest ready, right?

A lot of time is missed trying to find the proper guest who put their name on

the list, right?

So, we do in fact offer a client solution that uses one of those pagers, right?

When the table's ready, the pager buzzes.

So here I'm going to show off that pager opportunity.

Have you ever seen those where the thing buzzes and it's like, whoah, okay here.

So we'll show that off.

He also mentioned that he'd like to add other staff in different states and

in our current state of affairs, this isn't very extensible.

I can't very easily change the logic to the client specific wants.

I also have a couple of other demos later today and I don't want multiple copies of

this code out there nor do we have time to hack several these demos together.

So I feel like we need a different way of thinking of things to be able to pass

all these little added bits in.

It's like, we want the servers an assistance or our dashboard or

even our new pager to watch, or observe, the state of the table.

Wait a second.

Are you thinking what I'm thinking?

Should we be using the observer pattern?

What do you say we use it?