All language subtitles for 039 Mutable and Immutable Objects_en

Objects can be immutable or immutable.

In the past, we separated primitive types from class types.

We can also separate class types into two categories, immutable and immutable.

In this lesson, you're to learn to tell the difference between mutable and immutable objects.

To access this lesson, follow this path and your resources and open up the mutable folder.

Now, another name for Setar is Mutator before we continue to take some time to absorb this sentence.

Immutable object is an object whose field values can change.

Immutable object uses Mutator is Setas to update its fields.

And so inside Maine, the first line creates an object of the car class.

Let me ask you this, is car a mutable or an immutable class type?

Take a couple of seconds to think about it.

The answer is mutable after you create a car object, it's possible to update it.

In other words, the mutable object can use its mutator as its setas to update its fields.

And so to keep things simple at its core, what makes an object immutable after creating the object,

Wicken updated state, that's it.

We can mutate it.

Now, what is an immovable object, an immutable object is an object whose field values cannot change,

an immutable object does not have Mutator doesn't have Setas.

And you can access this part of the lesson by following this path and the resources and open up the

immutable folder.

Can I go inside, Main Espersen, immutable or an immutable class type?

Think about it.

The answer is immutable after you create a personal object, it's impossible to update it.

All of the fields are private and the person class doesn't have any setas.

This makes every object of the person class immutable.

It's impossible to update the state of a person object after you create it.

This leads us to the reference chart, mutable objects are vulnerable to the reference trap.

Immutable objects are immune to the reference trap.

So these two tables don't make any sense.

The reference job doesn't apply to immutable objects, so the tables need to specify that mutable objects

are the ones that are prone to the reference trap.

Let's do just that.

OK, this feels better.

You now inside main job, we're going to set another variable equal to the first object.

And then I'm going to update the object from the second variable.

Then I'll print the gold from both objects.

Run the code.

And unsurprisingly, updating the state of the second variable affects the first one.

When you set a variable equal to another, it copies the value inside in this case, what's inside is

a reference, and now both variables share a reference that points to the same object.

If I update the object there, one variable, it's going to affect the other.

And so mutable objects are vulnerable to the reference trap.

What about immutable objects?

Inside Main Java set another variable equal to the first person object.

OK, what now?

Every object of the person class is immutable, the fields are private and the person class doesn't

have any setas.

So even if both variables share a reference to the same object, there's nothing you can do to update

the state of either one.

Let me just put breakpoints.

You can visualize the runtime.

And so here, both variables share a reference to the same object, but that doesn't matter because

we can't update either one.

All you can do is set the second variable equal to a brand new object.

But in that case, the second variable story is a new reference that points to a unique object.

And so I hope you can see that immutable objects are immune to the reference trap.

OK, so first we need to update this table, because we can also divide class types into two categories,

mutable and immutable.

Mutable objects can update their status, immutable objects cannot mutable objects are vulnerable to

the reference Tropp immutable objects are immune.

Array is a mutable object, there is a class for every array type.

There's a class for array of integers, array of double array of long, etc..

So looking at this example, the variable equals the new object of the entire class.

The variable stores a reference to an object, the variable can be no, it can call methods, you can

update the state of an array, and arrays are vulnerable to the reference trap.

And since arrays are mutable objects, we don't need these two tables, the Redundance.

Remove them.

And this looks a lot better.

Let's recap, you learn to tell the difference between mutable and immutable objects.

You can update the state of immutable object, but you can't update the state of an immutable object.