为什么使用封装进行数据隐藏？

Question

Here is a very simple code example:

public class Name {

    public string Name = "John"

}

If you made an instance of the Name class in another class( Name n = Name(); ), you can change the Name string of the instance by doing n.Name = "Chris"; . However, this will just change the name for the instance of the Name class not the class itself. If you made a new instance of the Name class( Name na = Name(); ), and called the Name variable, it will still be "John" not "Chris".

I know that one of the reasons encapsulation is used is that so the user can't modify variables in a class. In the above example I showed, the user is not modifying the variable of the class itself.

Answer 1

Let's say you load a data from a server or local database and you parsed it to your own object. For example, user's profile.

class User {

    public static final String TAG = User.class.getSimpleName();
    private String name; 
    private String userToken; 
}

The User class doesn't have any default or static values because the data will be fed by the server.

The data you get from the server or DB will be something like,

name: John
userToken: 0x23fa8.... 

If the fields in your User class is public, the user (or any other parties) will access to the data and manipulate it. Think about the case the user changed his/her AuthToken, device id, or backup key phrases, etc... and if this manipulated data gets committed, it will cause a lot of trouble and clearly not what you want.

Just like @StalematOfTuning said, encapsulation is about protecting object instance's fields, not protecting pre-defined, class variables. If you only want to create a class with pre-defined class properties (static values), there's really no point of constructing a class because the class you created cannot be reusable for any other situation.

For example, if you already know the Name class will have one and only value, "John", it is wasteful to even constructing a class. The whole point of creating a class or an object is to reuse it for any possible input or data.

Answer 2

OK so I think you are confused about a few things here.

For starters, let's clean up this example a bit so it's easier to follow. I'm going to make a Person class:

public class Person {
    public String name;
}

Doesn't get much simpler than that. So, right now I have defined the class Person but it's important to note that no Person objects actually exist yet. The class Person can be thought of as a blueprint for making Person objects. So, let's make a person:

public static void main(String[] args) {
    Person john = new Person();
    john.name = "John";
}

Here I have initialized a Person by calling its default constructor (note the word new ), and set its name property to "John".

Now, if someone else was using this code they could come along and say hey let's change his name because why not?

john.name = "Bob";

But wait... a person's name changing might not make sense in the context of our program. Perhaps we don't want people to be able to change their names whenever they want as it might cause us problems later down the line. Even worse, someone could try and do something weird like turning his name into a number or any other crazy garbage that completely breaks the program. We can fix this by instead encapsulating the name property. We do this by making name a private field and define a constructor as well as a way to view that field.

public class Person {
    private String name;

    public Person(String name) {
        this.name = name;
    }

    public String getName() { 
        return name;
    }
}

Now, we must define what we want name to be when we create the object. Let's make John again:

Person john = new Person("John");

But most importantly, there is no way to change John's name anymore . Since we have not provided a public way to do so, it is impossible.

If we try to change john now, our program will not compile:

john.name = "Bob"; //NOT ALLOWED

And to view our name , we will instead have to use our getter method:

System.out.println(john.getName()); //prints "John"

This is the essence of encapsulation: protecting an object's properties from undesired changes in state. Instead of just handing over our data, we hide its actual state and only allow actions on it through controlled channels. If we did want to allow names to be changed, maybe we are ok with it but only if the new name meets certain criteria. Let's say: the new name has to be at least 3 characters long (sorry Al). We can provide a setter like so:

public void setName(String newName) {
    if(newName.length() < 3) {
        System.out.println("name is too short!");
    } else {
        name = newName;
    }
}

In this way we can have much greater control over how our data is used. I hope this helps clear up your confusion a bit.

Also note that if you create a new Person you will again need to specify another String to use to set its name in the constructor. Every object must be uniquely initialized.

Answer 3

why use encapsulation for data hiding?

A major advantage of modular code development is that modules can be uncoupled from each other. Modules that are not coupled have no dependencies upon each other. This means that they may be developed independently and in parallel. Moreover, as long as the contract that governs the behavior of modules does not change, then modules that are uncoupled can be modified or rewritten at any time without breaking the system in which they operate (as long as the behavior of the module continues to conform to its contract with other modules, ie its API).

Consider something like:

public class A {
    public String name = "Hello";
        :
        :
}

public class B {
    private A myA = new A();
    myA.name = "Hello World!"
        :
        :
}

We have written B to be dependent upon the way in which A has been implemented: namely that A has an instance field named name . The modules A and B are now coupled to each other because B depends upon A having this instance field. If we ever decide to change the way that A is implemented, we may be in trouble because a major overhaul to A may require a major overhaul in B.

Data hiding is valuable because it avoids this problem. We want to write B in a way such that B depends only on the behavior of A (ie, it's API) and not at all on how that behavior is implemented. That A has an instance field name is an implementation detail and we want to keep those details separated from the rest of the software system. It is usually true that any mutable fields that comprise the state of your objects should be hidden from other parts of the system. They are implementation details that should not be made a part of the API that modules export to the rest of the system.

TL;DR: Generally speaking, the more uncoupled modules are, the easier and cheaper they are to develop and to maintain.