[MUSIC]

Have you ever heard the old Boy Scout rule always leave the campground cleaner than

you found it?

As software developers we want to adopt this similar rule.

Every time we make a change to our code or someone else's code we want to try and

clean it up or improve it in some way.

We don't necessarily want to make any big changes.

But if we see an opportunity to, let's say use a variable,

instead of a hard-coded value, then we should make and test that change.

The important thing to emphasize here,

is that we don't want to change the behavior of the code.

We're just looking for opportunities to make it a little cleaner and

maybe more efficient.

Or maybe more maintainable for someone else to work with in the future.

This process is known as refactoring.

Let's see how we can do some refactoring with our fun fact code.

Right now, we have all of our code in this fun facts activity class.

And it works fine.

But what if we want to add a new activity that

also randomly selected one of our fun facts?

We could copy all of this code and add it to the new activity.

But then we would have the same code doing the same thing in two different places.

Then if we change this code for

some reason we'd have to remember to make this same change in the other activity.

This violates a core principle of software development.

The don't repeat yourself principle.

A better solution is to move the code that is repeated to a reusable component.

In this case, that can be a new object that can be used in multiple activities.

We learned before that activities are used to control how things work on the screen.

Our code does that, but

it also controls how the factors generated behind the scenes.

Let's make an object that separates out fact to generation.

Not only will it make our code a little cleaner, but

it will also prevent us from repeating ourselves in code.

It's another good programming practice to give each class a single responsibility.

So in our case,

the fun facts activity class will handle only how the screen looks and works.

And then new object, which we'll call fact book, will only

handle things about the facts themselves like how they are stored and selected.

This is another programming principle known as the single

responsibility principle.

All right, let me open up the project pane and then create our new fact book object.

There are a couple ways to do this.

We can go File, New and then pick Java Class, or

we can right click on our package and select new Java class.

I'll choose this option.

Then for the name, let's type FactBook.

And since we're making a normal class, we can leave this as is and click OK.

And here's our new file.

If we look over to the project pane,

we can see that a new FactBook file has been added to our package.

And our package now has two classes in it.

Also, at the top of our class, Android Studio has added a comment for us.

I'm not a big fan of this automatic comment, but luckily,

we can change a preference to make this not happen in the future.

Follow along if you'd like.

I'm going to click on Android Studio and then open the Preferences window.

Then expand Editor and select File and

Code Templates and over on the Includes tab select File Header.

And then delete everything in the window on the right, and hit OK.

We still need to delete this comment by hand though.

This class will be the blueprint for our FactBook object.

Remember that an object has two main components.

Fields or Member Variables which are properties about the object,

as well as Methods which are the actions the object can take.

This object only needs to do one thing, get a random fact.

Let's define a method for it.

We'll call it get fact, and

it will return a string, which will be the randomly chosen fact.

Right after our methods comment, let's type public String getFact,

with open and closing parenthesis, an open curly bracket, and hit Enter.

Now we just need to make this method return a random fact.

Let's cut and paste some code from our activity class into our getFact method.

This is the refactoring part.

Over in FunFactsActivity, and let me hide the project pane,

select everything here in the onClick method, except for

the last two lines where we're actually setting the text.

Since setting the text is part of how the screen looks,

it should stay as a responsibility of our activity class.

Then let's cut the text with Cmd or Ctrl+X.

Let's leave this error for now and go back to our FactBook class and

paste in the code.

We didn't copy over any of our imports.

So hit OK to let Android Studio automatically create the ones we need.

GetFact now gets a random element from the facts array.

But we still need to return which fact was selected.

So instead of setting up a fact variable with a random fact,

let's just return the random fact.

Nice, we've just made a new FactBook class and

given it a method which will return a random fact.

Let's take a short break, and then we'll see how to use our method and

fun facts activity.