• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Encapsulation

 
Ranch Hand
Posts: 509
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the Master Exam Explanation I read,
Encapsulation limits the consequence of change, allows corrections to a class with minimal impact on users of the class.

But isnt this the property of Coupling??
 
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, the thing is that if you have poor encapsulation you are leaving the door open for other classes to be tightly coupled with your class. Once you have poor encapsulation, whether other classes become tightly coupled with your class (that happens if the code in those classes bypasses the public interface of your class and accesses directly the variables that should not be publicly accessible) or not is out of your hands.

I really don't see how you can have tight coupling without poor encapsulation, based on the definition of coupling that is given in K&B (and which reflects the accepted definition for the SCJP 6 exam.)
 
Abhi vijay
Ranch Hand
Posts: 509
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok that means the dependence of Coupling on encapsulation is why we can say that Encapsulation makes it easier to re-use classes.
Am i right?
 
Ranch Hand
Posts: 352
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think, you are using the terms to loosley (excuse the pun ). Encapsulation in an encouraged design principle, to prevent negative manipulation of your class from outside influence. Coupling I will suggest is also a design principle, but is a result of a range of factors not just encapsulation. Tight coupling for example is dissuaded in Java, that is the ability for once class to influence another (such as through some form of interdependence). One still may have well encapsulated code, but within this code there still may be factors which suggest a tight coupling relationship (such as a private instance of another class, which has control over the class in which it resides).

 
Ruben Soto
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephen Davies wrote:I think, you are using the terms to loosley (excuse the pun ). Encapsulation in an encouraged design principle, to prevent negative manipulation of your class from outside influence. Coupling I will suggest is also a design principle, but is a result of a range of factors not just encapsulation. Tight coupling for example is dissuaded in Java, that is the ability for once class to influence another (such as through some form of interdependence). One still may have well encapsulated code, but within this code there still may be factors which suggest a tight coupling relationship (such as a private instance of another class, which has control over the class in which it resides).


Stephen, I am simply going by the definition of tight coupling given in K&B. Can you show me an example of how, according to that definition, you can have tight coupling without poor encapsulation? Also, how can an instance reference have control over the class in which it resides? I'm a little confused by that.
 
Stephen Davies
Ranch Hand
Posts: 352
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Firstly for an instance reference to have an influence over a class it resides, see Campbells post here

https://coderanch.com/t/411693/Java-General-beginner/java/coupling-cohesion-java

The Car Instance variable (in this case MyCar ref) has control of the goFaster() method of the Driver Class.

Even If you make the myCar reference private, then it still has controll over the goFaster() Method despite being hidden from outsiode the Driver class. What about this:



Ok so this is pretty basic, but the BankAccount is Encapsulated according to JavaBean specs, but still is influenced by the cutomer class is it not?



 
Ranch Hand
Posts: 952
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Abhi vijay wrote:Ok that means the dependence of Coupling on encapsulation is why we can say that Encapsulation makes it easier to re-use classes.
Am i right?



Yes you are right Abhi.
 
Ruben Soto
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephen Davies wrote:

The Car Instance variable (in this case MyCar ref) has control of the goFaster() method of the Driver Class.

Even If you make the myCar reference private, then it still has controll over the goFaster() Method despite being hidden from outsiode the Driver class.


Stephen, I think you are a little confused in that example. The problem here is not that myCar has control over the goFaster() method (which it doesn't.) The problem is that the goFaster() method directly accesses the implementation of the Car class because the Car class is poorly encapsulated (the speed instance variable does not have access protection.) Thus, the Driver class becomes tightly coupled to the Car class. If the Car class coder decides to change the implementation (for example, change the name of the speed instance variable, make it private, or simply remove it,) it will break Driver's code. Again, the tight coupling in this case is a direct result of poor encapsulation.

Stephen Davies wrote:
What about this:



Ok so this is pretty basic, but the BankAccount is Encapsulated according to JavaBean specs, but still is influenced by the cutomer class is it not?



In this case it's the Customer class that is poorly encapsulated (the balance field has default access, which means that any class in the same package can access it freely.) Whether this should be acceptable or not is debatable (you can argue that since both classes are in the same package, and probably under the control of the same programmer, this should be appropriate. I personally think it's still poor encapsulation.) Again, the class BankAccount becomes tightly coupled to the Customer class because Customer is poorly encapsulated. It's not the BankAccount class that has poor encapsulation, but the Customer class.

So unless I see a counterexample, I still think that tight coupling (as defined by K&B) can only take place through poor encapsulation.
 
Blueberry pie is best when it is firm and you can hold in your hand. Smell it. And smell this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic