Okay. So let's walk into another common scenario

that you'll encounter in your development travels.

Now, you'll definitely see this homegrown style implemented in other code bases, and

most likely, you'll have the temptation to do it yourself.

Okay. So,

I've got a pretty straightforward example that we can use to create that,

hey, I should use that observer pattern, feeling.

Now, the idea is that we have a universal remote control.

One of these that controls all sorts of devices.

I think if we just focus here on the power button, we can get there pretty quickly.

When I press the power button, I want all the devices on this control to turn on.

Let's take a look at some proof of concept code for remote control.

So, let's open up the universal remote module right here, right?

So in the source directory here,

you'll see that we have com team treehouse remote, and there's a devices package.

Let's take a look at our Blu-Ray player here.

Let's open this up.

So, it has some methods on it, and it extends the abstract class device.

And device has it announce, and it has the ability to toggle power.

So, every device is able to be powered on and off.

So, let's see what else extends this.

So, we have a stereo, and the stereo has the volume up and

down, and it also has the power on and off, because the device.

So, what else do we have here?

We have the remote control itself, let's take a look.

So, the current implementation.

Okay, it takes two of the devices that we have talked about, and

it stores them for later.

Yes, that works, and it also calls when it calls press power button,

it calls the toggle power on each of those devices that it has.

Okay, so let's look at application here.

So, it creates the two passes, and then the remote control,

and it presses the power button a couple times just to make sure it works.

Let's go ahead, I'm going to click this and choose run application main.

And in fact, it does, it powers that on, the Blu-Ray player gets powered on, and

press it off and then power it off.

Okay, cool.

It works.

Now, I just bought a new Apple TV, and

I'm pretty excited about it, but I don't want another remote.

So, I'm just going to install it here.

How am I going to do that?

So, that means in order to add it, I'm going to have to modify this remote

control file, or I'm going to have to add it to the constructor, and

that's kind of gross, isn't it?

There's a software design principle that states a class should be open for

extensibility, but closed for modification.

Now, this is the Open Closed Principle that the teacher's notes for more.

Now, if we have to add that Apple TV to the constructor, and

save a new type, we'll be modifying that class, and

we'll do that every time we want to add a new device.

That's gross.

I mean, what if other people are using this remote control code?

We're going to have to be careful not to break their implementation.

I mean, I don't think that we want everyone to have to buy an Apple TV.

I'm sure Apple wouldn't complain, but still, we should make this class open for

extensibility.

Are you feeling it?

Are your observer ears burning?

We should make our devices observe the pressing of that button,

and we should allow them to register themselves, right?

So, we could create a new button class and make it extend Java util observable,

and then add an instantiated button to the class and

we could make our device implement observer.

But that seems like a little bit of overkill, doesn't it?

Why don't we just keep a list of devices and

loop through them one by one and turn on the power?

Should we give that a go?

Okay, so first in the remote control, let's get rid of this, and

let's get rid of the constructor too.

Let's just make a new list of devices here.

We'll say a private list of device, and we'll call that devices.

And we'll make that a new array list.

And a new character, and we'll make that new array list.

Okay, and

we'll add a method that will allow us to register a device.

So, we'll say public void device.

I want to take the device and

close the device.end device.

Finally, we'll just loop through those devices and call toggle power.

Right.

So let's try that.

So we'll say for device and device in devices.

I'll say device.toggle.

Now, in the application code, we just need to change this just a touch, right?

So we got rid of that constructor, let's get rid of this altogether.

And let's move this up to the top here.

So we'll make a new remote control.

We'll build those new things.

And then we'll say rc.addDevice.

And we'll add the Blu-Ray.

And we'll add the stereo.

And let's make sure that it's still working.

Let's run it.

And sure enough, it's still working, nice.

And now just to show off, let's make an Apple TV.

Happen to know that they're not as easy to make as this.

So, we'll make a new class, and the device is here called Apple TV.

And it's going to extend Device.

We could fill this out with whatever we want, but

because it extends Device, we can toggle the power.

Pop over here, and I am going to say,

[INAUDIBLE] AppleTv.

And we can just say rc.addDevice, tv.

And run this again, and boom.

Now, everything's powering on, and everything's powering off.

So, because we left that class open for extension, we could keep it closed for

modification.

Awesome, right?

That was so quick.

Wait a second, what do we do about the other buttons?

How could we do that?

Is observer going to work to turn the volume up and down?

This is working because the method names are the same, right?

All the devices have the same toggle power, but

not all the devices have volume controls.

Looks like it's time to start hitting the Design Patterns book and tutorials.

Another benefit of the home grown approach is that you can

fairly quickly test your assumptions an iterator to see if the pattern is

actually the solution you needing.

Now, this is the need to create additional classes as an implementations.

The parametrized types a specific method calls really help legibility.

However, it does lead to the problem of not specifying that you were,

in fact, using the observer pattern.

If you were in the know,

would you be aware that this code was using the observer pattern?

It is definitely something that we are giving up by not using the very explicit

observer interface.

A side benefit of using this approach is that it usually ends up leading you to

other patterns.

For instance, I'm pretty sure, thinking through the other buttons on the remote,

that we are looking for a few patterns here.

I think we should probably look into the command pattern.

Check the teachers notes for more thoughts on that approach.

Now, in the interest of rapidly prototyping and iterating, we should take

a look at what the functional approach to this pattern entails.

These are starting to gain momentum as the quickest way to prototype a solution.

Let's do that right after this quick break.