Encapsulation Broad theory

Question

I am studying Java and have come to the Encapsulation section of the book.

For data "hiding", is the point of encapsulation to protect the primitive variables from being changed by any part of the program?

Are setters there to allow you to only allow variable change if it's truly needed? As in, with conditions set up within the class itself.

As an example. I have a "bank balance", and I want to see the balance if i were to buy something, but it hasn't been "charged" yet, so the variable would not be changed until after the charge is complete, thus meeting the condition the bank would have set for a true balance.

That is a very broad example, I realize i could just code it this way, I'm just asking as an example.

Answer 1

Yes, it prevents other classes from directly access private variables of your class.

Think of it this way:

Compared to this:

With the setter (and encapsulation as a whole), you have the chance to implement additional logic to decide how your variable is set, giving you an extra layer of control. You can add an algorithm to deduct some fees before money is taken from the account, or in this case, do extra checks to prevent this evil class from doing damage. There are more robust ways to do these things though using design patterns, but for you to appreciate how encapsulation makes sense, I'm using them as examples.

Encapsulation is not simply about setters and getters though. It's the idea of limiting control to internal components of your program, by hiding the actual implementation behind a facade.

Answer 2

The distinction isn't between primitives and objects, but rather between private and public state. With a television, for example, you care about the volume setting and the channel it's on, but the user doesn't need to know (and shouldn't care) about the actual I2C commands sent to the amplifier and PLL chips.

Encapsulation means clearly defining what items are public-facing and then hiding the rest, both so that the implementer can change the exact means by which the work gets done and so that clients can't screw up the encapsulated service's operations.

Setters, for example, exist so that an object can control how and whether its state gets updated. A method TV#setChannel(), for example, would probably change the channel field on the TV, but it would also perform some other actions to change the frequency the tuner was set at, perhaps display the new channel on the screen and so on. The client code shouldn't worry (or sometimes even know) about any of that.

In the case of a bank transfer, there are a number of other considerations as well, since multiple operations typically have to happen at once. More than object-level encapsulation is needed, but preventing client code from messing around with balances directly is part of the required solution.