• Post Reply Bookmark Topic Watch Topic
  • New Topic

how does encapsulation improve maintainability  RSS feed

 
john hog
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
can someone provide a good example of this? I understand making things private and using getters and setters to prevent corrupt data/valdiation. I am having trouble picturing a scenario where I can change my code without breaking others. What can I change without breaking existing code? One example I can think of is I can change an instance variable name since the getter for it will return it regardless. I am looking for a more vivid example or useful
 
Paul Clapham
Sheriff
Posts: 22834
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could start with a getter method which simply assigned its parameter to a private instance variable. Then you could modify that method to throw an IllegalArgumentException if, for example, the parameter value was less than zero. This wouldn't require any users of the class to recompile their code because it wouldn't change the method's signature.
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That may alter the general contract of the setXXX method. The following versions all maintain the general contract of such a set method:-If the user enters a mark of -1 or 999, you can blame him for not following the instructions. The second version is slightly more assertive:-The user will receive an error message, but may not be able to do anything about it.
Version 3 is slightly better, in that it always sets marks in the correct range, but that might not necessarily be what you really want:-
Version 4 is full‑blown defensive programming:-This will not permit any marks outside the correct range, and makes users stay inside the correct range. It ought to have a @throws tag in the documentation comment, however.
If mark does not have private access, it is often possible to assign it from outside the class, which means the class' invariants can be breached.
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And as Paul C says, you can have all those versions of the setMark method without other code having to be changed at all.
 
john hog
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks, I can see a better understanding of why it is possible to improve code.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a somewhat different spin on this. I tend to stay away from getters and setters as examples for encapsulation because it can be argued that they in fact often break encapsulation.

Encapsulation contributes to loose coupling which in turn leads to more maintainable code. When code is loosely coupled, the ripple effect of changes can be minimized.

Encapsulation combines taking data and behavior together as one unit as well as isolating or hiding implementation details. Code outside of the "capsule" cannot depend on specific implementation details but rather only on a contract for behavior as defined by the API of the "capsule".

A good example of encapsulation is an Iterator implementation. The iterator implementation does not divulge its internal data structures nor does it divulge how it keeps track of which element is currently being iterated over. You can't even create an iterator because that knowledge is encapsulated within the "capsule" of the Collection that you're trying to iterate over. You have to ask the specific Collection to provide an iterator that you can use for it. The only thing that you can really count on is that the implementation adheres to the API defined by the Iterator interface. In other words, a well-encapsulated class means that you have no way of knowing anything about it that you really don't need to know.

Not divulging intimate details about the implementation of a class forces client code to be programmed entirely to the API. If you analyze tightly coupled code, you will most likely see the opposite: tightly coupled code often has classes with intimate "knowledge" of implementation details of other classes. This is where you get into maintenance nightmares because client code is not shielded from changes to the implementation of other classes to which they are tightly coupled.

The trick to writing well-encapsulated classes is knowing where and how to draw that TMI (Too Much Information) line.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!