Do both these classes support encapsulation and …?

Question

public class Normal {
   public string name;     // name is public

   public String getName() {
        return name ;
   }

   public  String setName(String newName) {
         


        

Answer 1

1. Different is a better example of encapsulation than Normal, though with something that simple, the benefits aren't really noticeable.

2. Different is theoretically easier to maintain, because if you want to change the internal representation of name, you can without modifying the public API.

3. Same as #2, for the same reasons.

4. While the first class allows users to directly modify name, the second makes them go through getName() and setName().

5. If something is unencapsulated, you're exposing all the nitty gritty inner details to the world. This is difficult, if not impossible, to retroactively change, because you'll break any existing code that uses it.

Answer 2

• The idea of getters and setters are to allow developers to execute other required logic to derive the value for a class field. Therefore leaving the class fields as public allows to skip executing the logic before assigning a value to that field.

• The second class is easier to maintain as one can be sure that the value of the name variable is always set through the setter.

• Again the second class is better for re-factoring as it exposes less members.

• If you imagine some other developer using the "normal" class, he may choose to set the value of name directly, instead of using the setter. Therefore if in future you decide to change the visibility of the "name" variable, you'll break the other persons code. In such a simple example this isn't important, but when writing important code, this tends to become problematic since you don't want to break other developers code by change the visibility of a variable. Hence not encapsulated code is unchangeable.

Generally speaking, a better design tends to expose less moving parts. But in addition to that encapsulation narrows the number of ways that the internals of your class can be manipulated by other codes.

Answer 3

In "Normal" (there's nothing "normal" about that), this is perfectly legal code:

public static void main(String args[]) {
   Normal normal = new Normal();
   normal.name = "suhail gupta";
   System.out.println( "My name is : " + normal.name );    
}

Your interface now includes a String value called name. Users will expect to be able to set it using either VarName.name or VarName.setName syntax. Users will expect to be able to retrieve it either with VarName.name or VarName.getName;

For example, this is legal in "Normal":

public static void main(String args[]) {
   Normal normal = new Normal();
   normal.name = null;
   String name = normal.name;
   System.out.println( "My name is : " + name );
}

Now, maybe you'll think "so what?" Imagine if the setting of the variable to null was separated from the actual printing (where the error happens) by 30 files. It will be very hard to know who screwed up the value of that variable. And there's nothing you can do to prevent the user from screwing it up.

Now, if you had implemented setName as this:

public String setName(String newName) {
   assert newName;
   name = newName ;
   return name ;
}

Then, the error happens immediately upon the user doing something wrong. The user tried to set a value to null that isn't allowed to be null, therefore error. You have a call stack that shows where the error happened, and this is much easier to debug.

Of course, that doesn't help because the user of "Normal" does not have to use setName. They are free to poke at name directly.

While it may technically be encapsulation, as far as I'm concerned, if the user can easily and trivially subvert it, it's not encapsulation. If there's no protection, there's no encapsulation.

---

When they say Unencapsulated means Unchangeable , how it is unchangeable here ?

OK, let's say you give me a library containing Normal. I will use it in some way. Maybe I've got Normal instances scattered over 50 files. They all directly set and get the name by the name rather than the accessors. This is perfectly legal because you made it public.

Now, you decide, for whatever reason, that you don't want to store the name in a string. Maybe you need to be able to have a first name and a last name. So, let's say the next version of your library has this definition:

public class Normal
{
    public string firstName;
    public string lastName;

    public String getName()
    {
        return firstName + " " + lastName;
    }

    public  String setName(String newName)
    {
        //parse newName into a first and last name.
        ...
        firstName = newFirstName;
        lastName = newLastName;
        return getName();
    }
}

What's missing? public String name; That's no longer available, because you now have a first and last name. Notice that the two accessor methods did not change at all.

When I upgrade to the new version of your library, you will have just broken all of my code. I don't like my code to be broken simply because you decided to change how you stored the data in your class. I will now never use anything you make again, because you can't even keep your interface consistent from one version to the next.

And if you had just done things properly, none of that would have happened.