need for Encapsulation ?

[munjal upadhyay]

If the private variable you want to protect, can stil be changed with the setter mathod....

then
Why need to use the Encapsulation ?

[Ogeh Ikem]

Encapsulation (actually data hiding) protects data because data can be accessed in a safe way - the same way your bank account is secure because it can be accessed in a safe way. In some classes, there are rules for accessing data so that the class is always in a consistent state. These rules can be defined in a method and everyone is forced to comply with these rules by making the data private and the method public. It's like saying if you want to access this private data, you must first comply with these rules. If everyone was allowed to directly access the data without complying with the rules, there is a good chance that the class will be left in an inconsistent state. For example, if you want to ensure that users cannot set age to a value less than 0, you can make age private and provide this setAge() method

public void setAge(int age){
if (age >= 0) {
this.age = age;
}
}

Encapsulation also has the advantage that the rules can be modified without having to modify every client.

[Pat Farrell]

expanding on @ogeh's response:

Consider a member variable containing a phone number. The trivial implementation has it as a String. You could have code such as:

private String phoneNumber;
public String getPhoneNumber() { ....}
public void setPhoneNumber(String arg) ....

If you were only working on US phone numbers, you could store it as a ten digit string. And you could easily add validation to it.

At a higher level of functionality, you could decide to implement phone numbers the way they actually work in the US. The ten digits are not all equally important. There is information encoded in the ten characters:

first three digits are area code

second three digits are "exchange" or "central office"

Last four digits are "line" within the central office

With encapsulation, you can change your PhoneNumber class, and validate and return each of these fields, adding getter methods such as
public String getAreaCode()
public String getExchange()
public String getLine()

[munjal upadhyay]

 

Pat Farrell wrote:expanding on @ogeh's response:

Consider a member variable containing a phone number. The trivial implementation has it as a String. You could have code such as:

private String phoneNumber;
public String getPhoneNumber() { ....}
public void setPhoneNumber(String arg) ....

If you were only working on US phone numbers, you could store it as a ten digit string. And you could easily add validation to it.

At a higher level of functionality, you could decide to implement phone numbers the way they actually work in the US. The ten digits are not all equally important. There is information encoded in the ten characters:

first three digits are area code

second three digits are "exchange" or "central office"

Last four digits are "line" within the central office

With encapsulation, you can change your PhoneNumber class, and validate and return each of these fields, adding getter methods such as
public String getAreaCode()
public String getExchange()
public String getLine()

I get you but not perfectly
the same thind you can do without Encapsulation.

Can you send me a small program please..

[munjal upadhyay]

 

ogeh ikem wrote:Encapsulation (actually data hiding) protects data because data can be accessed in a safe way - the same way your bank account is secure because it can be accessed in a safe way. In some classes, there are rules for accessing data so that the class is always in a consistent state. These rules can be defined in a method and everyone is forced to comply with these rules by making the data private and the method public. It's like saying if you want to access this private data, you must first comply with these rules. If everyone was allowed to directly access the data without complying with the rules, there is a good chance that the class will be left in an inconsistent state. For example, if you want to ensure that users cannot set age to a value less than 0, you can make age private and provide this setAge() method

public void setAge(int age){
if (age >= 0) {
this.age = age;
}
}

Encapsulation also has the advantage that the rules can be modified without having to modify every client.

You are rite that no one can enter the Negative value (we can allow the restriction with the Encapsulation)
However , if the one who insert the negative value will got the problem , your data is still safe.

even , if you use the Encapsulation, one still can paly with the Encapsulated (private) value with using public method.

And as you mention the example of account password , the one who want to change or play with your password can still do the same (wether you use Encapsulation or not).
so how can you protect your data.

[Ogeh Ikem]

Your data is safe because it is protected from illegal modification. Anyone who wants to modify data must comply with your rules.

[munjal upadhyay]

 

Ogeh Ikem wrote:Your data is safe because it is protected from illegal modification. Anyone who wants to modify data must comply with your rules.

Thats the only facility the encapsulation has...

[Geeta Puttappanavar]

 

munjal upadhyay wrote:

ogeh ikem wrote:Encapsulation (actually data hiding) protects data because data can be accessed in a safe way - the same way your bank account is secure because it can be accessed in a safe way. In some classes, there are rules for accessing data so that the class is always in a consistent state. These rules can be defined in a method and everyone is forced to comply with these rules by making the data private and the method public. It's like saying if you want to access this private data, you must first comply with these rules. If everyone was allowed to directly access the data without complying with the rules, there is a good chance that the class will be left in an inconsistent state. For example, if you want to ensure that users cannot set age to a value less than 0, you can make age private and provide this setAge() method

public void setAge(int age){
if (age >= 0) {
this.age = age;
}
}

Encapsulation also has the advantage that the rules can be modified without having to modify every client.

You are rite that no one can enter the Negative value (we can allow the restriction with the Encapsulation)
However , if the one who insert the negative value will got the problem , your data is still safe.

even , if you use the Encapsulation, one still can paly with the Encapsulated (private) value with using public method.

And as you mention the example of account password , the one who want to change or play with your password can still do the same (wether you use Encapsulation or not).
so how can you protect your data.

You are telling to validate the age fielde. We can validate it by using sruts validation fm also rite?? Then why to go for setter method validation???

[Martin Vashko]

Hi Geeta, and welcome to the Ranch!

I'll try to answer this specific question of yours, but it is better to continue the discussion on the encapsulation in the thread you've started.

Even if you validate all parameters outside the class, it can still make sense to validate them again in the class (in the constructor and the setter methods). The reason is that the design of the class should not depend on the details of how the class will be used by the application. The setters might be used outside of the struts framework, or the validation in struct might contain bugs. It is always better to validate the parameter two times than not to validate it at all. Also, by sticking to validation inside a class it is easier to maintain the resulting code, since related things are stored together. To avoid duplication of code, you might create a helper class for the validation which would be used at all places the validation is needed.

Note that the post you quoted is not the best example of how validation should be done. Even if we assume that any positive integer (eg. 1000) is acceptable as an age, the setter method probably should throw an exception when the new age does not meet required conditions, instead of silently ignoring the error.