• Post Reply Bookmark Topic Watch Topic
  • New Topic

need for Encapsulation ?  RSS feed

 
munjal upadhyay
Ranch Hand
Posts: 69
Java Mac OS X Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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



Encapsulation also has the advantage that the rules can be modified without having to modify every client.
 
Pat Farrell
Rancher
Posts: 4686
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Ranch Hand
    Posts: 69
    Java Mac OS X Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 69
    Java Mac OS X Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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



    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
    Ranch Hand
    Posts: 180
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Your data is safe because it is protected from illegal modification. Anyone who wants to modify data must comply with your rules.


     
    munjal upadhyay
    Ranch Hand
    Posts: 69
    Java Mac OS X Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 46
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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



    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 Vajsar
    Sheriff
    Posts: 3752
    62
    Chrome Netbeans IDE Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!