• 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 makes it easier to reuse classes?

 
Ranch Hand
Posts: 40
2
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just like the person who posted this more general question, a few years back, I encountered this statement in a K & B test exam:

"Encapsulation makes it easier to reuse classes"

I also did not select it. After thinking some more about this I came to the same conclusion as the original poster there: high cohesion and loose coupling makes it easier to reuse classes. Encapsulation does NOT mean that the class actually has high cohesion and loose coupling. E.g. a single class may have high encapsulation yet provide uncohesive and highly coupled functionality, e.g. one class that contains all the code required to ask the user to enter data for a report, store it in a database and print it. This class cannot easily be reused to print something else than this report or store the data but not print it at this time. Or print data that is already in the database without having the user enter it at this time. This kind of low cohesion and high coupling is what generally makes reuse harder.

In my view encapsulation means: to hide internal state and implementation details from the client code of a class. This means you provide an API to control changes to the state. In terms of Java this means that fields should not be made public and the API consists of public methods that may manipulate the state. The changes that can be made to internal state using the public methods should be as minimal as possible while still satisfying the requirements for the client of the class. This ensure that the internal implementation details can be changed without breaking the client as long as the external behavior stays the same.

I don't really see how it becomes harder to reuse a class when it has poor encapsulation. In fact, in practice I have had multiple cases where I had to jump through hoops to get well encapsulated widget classes (SWT/JFace/Eclipse) to do what I want. I resorted to reflection to change their state. (The above rule "still satisfy the requirements for the client of the class" is of course hard for API designers to determine in advance.)

One could argue that when exposing fields as public, an object gets harder to reuse because any code can change it at any time! But that argument simply doesn't hold because your own code can simply create a new instance of the class for private use. Because the class is poorly encapsulated you can actually do more with it, so it should in fact be easier to reuse!

It is true that a poorly encapsulated class can be harder to reuse when it has certain invariants between it's fields that need to hold. Exposing the fields directly enforces the client of the class - instead of the code of the class itself - to ensure that these invariants are not violated. This is an extra burden on the client of the class, so indeed it is harder to reuse!

Would this be their reasoning or am I missing a simple point...?
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Henno,

Encapsulation in Java with example says -

Advantages of encapsulation:
It improves maintainability and flexibility and re-usability: .... Since the implementation is purely hidden for outside classes ...



Regards,
Dan
 
Henno Vermeulen
Ranch Hand
Posts: 40
2
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Dan Drillich wrote:Hey Henno,

Encapsulation in Java with example says -

Advantages of encapsulation:
It improves maintainability and flexibility and re-usability: .... Since the implementation is purely hidden for outside classes ...



Regards,
Dan



Hi, I checked the blog post. On this topic it says

... Hence the code can be maintained at any point of time without breaking the classes that uses the code. This improves the re-usability of the underlying class.


I am missing a few steps here to understand how to reach that conclusion. I think this isn't immediately obvious if you look from the point of view of the code that reuses the class.

Perhaps the missing reasoning is as follows:
- assume that the reusable class requires maintenance
- maintenance is easier to do when the class is well encapsulated, if it is not, changing the class may break existing code that uses it
- so encapsulation makes it easier to reuse classes (because it prevents client code from breaking when the reusable class is maintained)

Still I feel that the statement "Encapsulation makes it easier to reuse classes" isn't true when you are given a class that never changes. The question never mentions maintainability, hence my confusion!
Perhaps it should have read something like "Encapsulation makes it easier to reuse classes that require maintenance" or "Encapsulation makes it easier to maintain reusable classes".

Do you think that this was the reasoning of the authors of the question, or is there another mechanism in which encapsulation helps improve reusability?
 
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Encapsulation increases maintainability. It actually does reduce reusability as you pointed out. At the least, it is debatable and the option should be marked incorrect. You may want to post the question to the author on publisher's forum.
 
Henno Vermeulen
Ranch Hand
Posts: 40
2
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alright I posted to the errata sticky topic for the book.
 
Ranch Hand
Posts: 175
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henno Vermeulen wrote:Still I feel that the statement "Encapsulation makes it easier to reuse classes" isn't true when you are given a class that never changes.


I’ve never heard of a class that never changes. A class can always be improved on. From version to version, an application must evolve and improve or it will die. This sometimes involves reusing classes i.e. swapping one class for another class (an improved version).

Encapsulation increases reusability because encapsulation decreases coupling by hiding the internal implementation details of a class from collaborating classes.

Low coupling increases reusability because one class can easily be swapped for another class (an improved version) without affecting collaborating classes.

Henno Vermeulen wrote:Because the class is poorly encapsulated you can actually do more with it, so it should in fact be easier to reuse!


Poor encapsulation decreases reusability because when you swap one class for another class (an improved version), you may break collaborating classes which directly access code that has changed in the improved version. This is why it is a good idea to encapsulate what varies i.e. encapsulate what may change.
 
Henno Vermeulen
Ranch Hand
Posts: 40
2
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree 100% with all you are saying. I think you have put into other words what I meant in my previous reply.

To summarize: encapsulation decreases coupling. Low coupling increases the maintainability of the class. This increases it's reusability.

Somehow I'm still left with a gut feeling that the question is debatable because this seems to be an indirect consequence of encapsulation and requires you to assume the presence of maintenance.
 
Paul Anilprem
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Joe Bishara wrote:This sometimes involves reusing classes i.e. swapping one class for another class (an improved version).


Your notion of what reusable means is incorrect. What you described above (swapping one class for another class) means replaceable, not reusable!
Reuse implies using something that is meant to do one task, to do another.
 
Joe Bishara
Ranch Hand
Posts: 175
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're right. That should be reworded. Encapsulation increases code reusability (the ability to reuse the same implementation) because encapsulation allows you to change the implementation to an improved version without breaking the system.

Paul Anilprem wrote:Reuse implies using something that is meant to do one task, to do another.


I think a class is supposed to have a single purpose (single responsibility) i.e. a class designed to do one task should not be able do another.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henno Vermeulen wrote:I don't really see how it becomes harder to reuse a class when it has poor encapsulation.


And what about a class likeHow could you reuse this class if it had poor encapsulation and the radius property is not private, but for example public? It wouldn't. Or it would be a lot harder, because you would lose the data inegrity check of the radius (and you have to do it manually every time you set the radius).
 
Henno Vermeulen
Ranch Hand
Posts: 40
2
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes exactly, if radius wasn't encapsulated, the client code is burdened with ensuring the invariants are not violated making the class harder to reuse. I am actually suggesting this may be the answer in my original post. Still I'm not sure if this is really the reason. A class could provide BOTH methods to enforce it's invariants AND provide direct access to it's fields.

Henno Vermeulen wrote:
...
It is true that a poorly encapsulated class can be harder to reuse when it has certain invariants between it's fields that need to hold. Exposing the fields directly enforces the client of the class - instead of the code of the class itself - to ensure that these invariants are not violated. This is an extra burden on the client of the class, so indeed it is harder to reuse!

Would this be their reasoning or am I missing a simple point...?

 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henno Vermeulen wrote:Still I feel that the statement "Encapsulation makes it easier to reuse classes" isn't true when you are given a class that never changes. The question never mentions maintainability, hence my confusion!
Perhaps it should have read something like "Encapsulation makes it easier to reuse classes that require maintenance" or "Encapsulation makes it easier to maintain reusable classes".

Do you think that this was the reasoning of the authors of the question, or is there another mechanism in which encapsulation helps improve reusability?


Let's have a look at these classes I wrote for my Crazy Zoo applicationNow if you want to reuse this class, you are required to use an array and convert your data structure to an array each time. Or maybe the data structure would even be more complex (e.g. a Map with AnimalType-List<Animal> pairs). Would this class not become easier to reuse if the data structure to store the animals was kept private and you have add and addAll methods?
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henno Vermeulen wrote:I am actually suggesting this may be the answer in my original post. Still I'm not sure if this is really the reason.


Oops, I missed that one. Sorry about that!

Because of the two code snippets I provided (and your suggestion in the OP), I'm convinced that encapsulation makes it easier to reuse classes and therefore I don't think it's an errata item. I also would have selected this option when answering the mock question.

I agree that encapsulation benefits (and increases) maintainability much more than reusability and it's probably much easier to reuse a single purpose (high-cohesive) class with poor encapsulation than a well encapsulated class having a dozen of different responsabilities. But the answer option just mentions that encapsulation makes it easier to reuse classes (not that this is the main advantage of encapsulation, nor that it's easier than having a high-cohesive class), so that's why I think that statement is true.
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henno Vermeulen wrote:Somehow I'm still left with a gut feeling that the question is debatable


This discussion clearly shows it's a debatable statement And I'm pretty sure if this question was on the actual exam and it stated to select 3 correct answers, you (and I) would not select that option (because 3 other options are a much better fit for encapsulation). But if the question would state to select 4 correct answers, you (and I) will select this option as well.

Hope it helps!
Kind regards,
Roel
 
Henno Vermeulen
Ranch Hand
Posts: 40
2
Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your answers. I think we can summarize this discussion by saying that:

encapsulation's main benefit is maintainability but generally does help for reusability.
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Great summary. Have a cow!
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic