Let's say that we've been tasked with designing a very simple horse racing game

to keep a friend entertained, and this is what we came up with.

Let's walk through the code.

At the top, we have a class Horse that represents a racer in our game.

As an aside, you can get all this code from

the code snippet linked in the teacher's notes with this video.

A horse has a name and a max speed.

We initialize a horse with these properties, a name and a max speed.

A horse does not run at their top speed for

the entire race, at least, I don't think they do.

Honestly, I have absolutely no idea how any of this works.

Anyway, because we're assuming they don't, we're going to vary their speed during

the race randomly by querying a currentSpeed computed property.

This returns a random value between a lower bound,

which I have set to be 13 meters per second, and the horse's maximum speed.

Very scientific, I know.

And to do that, we're using the arc4random uniform function to generate a random

number and then getting a value between the lower bound and that upper range,

which is the max speed.

In this naive implementation of the game, a horse keeps track of its progress

through a race in terms of the distance traveled per lap and which lap it is on.

Below that, we have a class called race.

A race is initialized with a number of laps and a set of participants.

So if you go all the way to the bottom, you'll see that we've defined a set of

participants with some speed values in meters per second.

We've put those in an array to define our participants and

then we've initialized a race.

A race also stores, if you look up at the top, a value for the length of each lap,

which for simplicity's sake, we've kept fixed at 300 meters.

The main logic of the race works around this timer.

So I've defined a timer over here that repeats every second and

calls the updateProgress method, which you see down here.

To start the race, we call the start method.

For now, that method is at the bottom, but it's commented out.

So I don't wanna start the race just yet.

When we call the start method,

this simply starts the timer by adding the timer to this program's run loop.

Ignore all that technicality for now, but

to get all this to work because we're using a timer and some complicated stuff.

We have to ask the playground page to run indefinitely,

rather than the one time execution that we're used to.

To do this, I have imported a framework up at the top.

Or I need to, rather.

So I'm going to import PlaygroundSupport.

And then we're gonna set a property on the current page to allow it to

continue indefinitely.

So we'll say PlaygroundPage.current.needsIndefiniteExe-

cution = true.

Okay, so now rather than normal, when the playground page

just executes top to bottom, this keeps the process running in the background.

The race logic is quite simple.

It's actually very simple and is housed in the updateProgress method.

So here, we iterate through all the participants in the race.

We increase the amount of distance traveled by the current speed.

Because our distance is in meters and our current speed in meters per second.

Since the updateProgress function is called every second by our timer,

this is an easy way to get the current distance traveled right there.

Note that we're using the current speed to do this,

which means that we'll get random values every time.

Now, the values won't vary by much.

But hopefully, that should make our races exciting.

After a horse has traveled a distance that's equal to the length of a lap,

we set the distance back to 0 and increase the lap count on that horse.

If any of the horses hit the max lap limit, the first one to do so wins.

And we immediately stop the race and break out of this for loop.

Okay, and then the stop method just invalidates that timer, so

the race is over.

And at the bottom, as mentioned earlier, we have a few players and

there's a race set up.

So let's see how this works.

If we uncomment the call to the start method, you'll notice in the console, once

this starts executing, that the race goes into progress, it's going and it's going.

And then after a while, this should stop.

Remember it's going in seconds, and there's 300 meters to cover.

So this is fun, but none of this is core to our problem.

The issue is that once a race is over, we don't really know anything.

We don't know who won the race, so all we see is it says race complete.

We don't know which horse was in lead at any particular time,

we don't know who finished lap one first and so on.

And we'd love to review these stats, so we can perform better in the next race.

So let's introduce a new class called tracker to handle this.

Okay, so I'm going to paste this code in above Race, and remember,

you can grab this code as well from the code snippets linked below.

So we've started here with a really naive, so to speak, implementation, and

we're just going to store all our data as key value pairs in this stats dictionary.

For now, the Tracker class just has a series of methods for

different data points that we want to capture.

And it logs these data points back to that dictionary using relevant keys.

So here, you see the updateRaceStart method that takes a time value,

and inside, we update the value on the stats dictionary.

And we use a set of keys that we've defined in the Tracker class as a private

struct, or a nested struct, rather.

Okay, so similarly, we update the LapLeader,

update the RaceEnd time with the winner, and so on.

And then we have a method to print the summary of the race.

To use this tracker, one way we can go about it is to create an instance

of the tracker as a stored property in the Race class.

So inside Race, we can say let tracker = Tracker.

Now let's log a few events.

So when we call the start method on the race, we'll log the event and the time, so

we'll say tracker.updateRaceStart with the current date,

and we'll use use the Date class to do this.

This is part of the foundation framework, and

when you initialize an instance, it captures the current time.

Inside the updateProgress method, we can also log events.

So this is not very technically correct, but we'll see.

So after, rather not here, but after this line,

we'll say let lapKey =, and we'll create a key.

So we'll say Tracker, and we'll use that nested struct,

Keys, to get the lapLeader string.

And then to this, we'll append the current lap, so we'll say horse.currentLap.

So this creates a key where we say,

if we look at the keys list and lap leader, it says leaderForLap,

and then we're adding one, two, or depending whatever lap they're on.

So now that we have a key, let's go back down here, and we'll say,

if !tracker.stats.keys.,

already contains this lapKey, then we don't wanna do anything.

But if it doesn't contain it, then we're going to call the tracker to update

the lap leader with the horse's current lap, the horse, and the current time.

Once the race is over, we'll log that as well.

So in the stop method, before we invalidate the timer,

we'll say tracker.updateRaceEndWith.

Actually, we can't do that in here, we need access to the horse, so

I'll do that right here in our logic, where we break out of the loop.

Right before we call stop,

we'll say tracker.updateRaceEndWith horse and current time.

Inside the stop method, once the race is over,

let's print the output of our tracker, so we'll say tracker.PrintRaceSummary.

I'm gonna let this run for a few seconds, and you'll see that once the race is over,

we should get more information about the race.

And I'm gonna drag this up, so you can see it.

Okay, so this seems like we've solved the problem, right?

Yay us, now some time passes, and our friend wants an addition to this game.

Not only does he want to race his horses, but

he wants to broadcast the race live to his friends on social media.

Now this includes information, like the start time of the race,

which horse led a particular lap, when the race ended, and who won.

Obviously, you notice that this is the same information that the Tracker

class cares about.

It would be easy to stuff this new functionality into the Tracker class.

But remember, classes shouldn't do more than one job.

So let's go ahead and create a new class right after Tracker here.

And we'll call this class RaceBroadcaster.

RaceBroadcaster cares about the same information that Tracker does,

except it does something entirely different with it.

Because this is a different class, we now need to add the RaceBroadcaster class

as a stored property inside class as well.

So we can say let broadcaster = RaceBroadcaster, and

we'll create an instance and assign it to the property.

So let's assume that we do this and make the changes where we want to broadcast.

So we provide methods here that capture the information and

then put it on social media, and we make the relevant calls inside race.

Things are great.

Down the road, our friend asks for yet another request.

Maybe I should have written up a contract?

Anyway he wants to gather all the data from all our races to build

a leaderboards page for various statistics.

Here's where we start to run into difficulties.

Tracker objects are tied to a particular race, as you can see.

This means that to gather up all the data across different races,

we either need to go through the race instances, or

after a particular race, extract the tracker and save the data elsewhere.

Leaving that aside, we also have this problem where the race knows about

the tracker and the broadcaster.

Does it really need to?

The race object shouldn't care about the fact that it needs to be tracked or

broadcasted.

This is far too tight of a coupling.

In a real race, does a jockey know that a particular TV station is showing this?

No, I mean these are concerns that need to be separate.

The important facts are as follows.

A race has certain events that are important.

When did the race start?

Who led at the end of a particular lap?

When did the race end?

Lots of other objects care about these events, but

it isn't the race objects' responsibility to implement them.

All the race object should do is indicate when these events happened.

If a tracker wants to track it, if a broadcaster wants to broadcast it, or

if any other object whose role we haven't defined yet

wants to use these events, it should just listen for them indirectly.

While the solution we have in place works right now, it leads to pretty tight

coupling, where only the objects we've currently defined can use this event data.

And to use it, it needs to be part of the Race class.

We want to implement a more flexible solution, where any object that adheres

to a particular contract can use the race's event data.

Let's do that in the next video.