• 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

What is encapsulation?

 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hey,
I am a newbie to java programming & i encountered statements like "encapsulation of businesslogic in beans"

Can i know what is the meaning of encapsulation with the help of a realtime example?

cheers,
Bye!
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the sentence you've quoted, the technical term "encapsulation" is really being misused, although it's a common mistake. In that sentence, it just means "implemented in". The business logic is implemented in Java Beans.

The technical meaning is stronger: encapsulation means hiding the implementation details of an object inside by making all its data private and carefully protecting these details from being exposed. Well-encapsulated classes are easy to test in isolation and easy to change over time without affecting other classes that use them.

Note that "realtime" means something like "happening right now, corresponding to a clock ticking;" maybe you mean a "realistic" example.
 
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The accessor(getter) and mutator(setter) methods are generally used to provide encapsulation. As the instance variables are private they can only be accessed outside the class through these methods.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ernest Friedman-Hill:
In the sentence you've quoted, the technical term "encapsulation" is really being misused, although it's a common mistake. In that sentence, it just means "implemented in". The business logic is implemented in Java Beans.



When I say something like that, I typically mean that the reason to having it implemented in Java beans (or whatever else) is to decouple it from other parts of the system. For example, I might say something like that when I'm talking about GUI code and want to highlight the fact that the GUI code doesn't know anything about the business logic.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you Google this question you'll find about as many definitions as there are "expert" authors and lecturers.

One aspect common to most definitions is "information hiding" mixed with "low coupling", terms that date to the late 60s or early 70s and deal with the stuff Ernest and Ilja talked about. If a class or component reveals its internal workings to us, we might write our code so that we depend on those internal workings. Then the owner of that component can't change it without messing us up. If a component conceals its inner secrets and only shows us a simple interface, we are much less likely to be harmed by future changes and it's much easier to swap in a replacement component if need be.

Another aspect that shows up in fewer definitions is "high cohesion", another term from the beginning of software design, meaning encapsulation brings things together that belong together (excluding things that don't belong) and builds them into a "whole thing" of some kind. A good class or component has a Single Responsibility or a Single Reason To Change.

The word "encapsulation" means so many things to so many people that it's good to back it up with some hints about what YOU think it means when you use it.
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Aum Tao:
The accessor(getter) and mutator(setter) methods are generally used to provide encapsulation.





Getter and setter methods are generally used to break encapsulation, not provide it. A truly well-encapsulated class has no setters and preferably no getters, either. Ideally, you don't ask a class for some data and then compute something with the data -- you ask a class to compute something with its data, and return the result.
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
If you Google this question you'll find about as many definitions as there are "expert" authors and lecturers.


So true. A tangible definition invalidates Java/OO altogether by showing that it is orthogonal to "encapsulation" and we can't have that in an economic world

Ever (really really as in deep analysis) wondered why a simple web application that does nothing more than handle incoming HTTP requests with a HTTP response, requires: Spring framework, Velocity, Hibernate, etc. etc. *yawn* etc.?
 
Aum Tao
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is from Kathy Sierra and Bert Bates Java Certification book:

If you want maintainability, flexibility, and extensibility (and of course, you do),
your design must include encapsulation. How do you do that?
■ Keep your instance variables protected (with an access modifier, often
private).
■ Make public accessor methods, and force calling code to use those methods.
■ For the methods, use the JavaBeans naming convention of
set<someProperty> and get<someProperty>.



Isnt' encapsulation provided by keeping the instance variables private and providing setter and getter/setter methods to access them?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Aum Tao:

Isnt' encapsulation provided by keeping the instance variables private and providing setter and getter/setter methods to access them?



That's a rather poor form of encapsulation. Even more encapsulation is achieved by not giving other classes access to the variables at all.

Notice, though, that maximixing encapsulation cannot be a good design goal - a fully encapsulated class would be useless, as it couldn't communicate to the outside.

Instead, you need to strive for a balance between different forces. Still, accessor methods should be used with much care, in my opinion.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ever (really really as in deep analysis) wondered why a simple web application that does nothing more than handle incoming HTTP requests with a HTTP response, requires: Spring framework, Velocity, Hibernate, etc. etc. *yawn* etc.?



Going off topic, but sure. For a web site that just spews out static pages and a few database queries, all that stuff is overkill. If that kind of site was my goal, I'd probably learn Ruby and get on with it.

What I do for a living is a different animal that happens to include HTTP at the boundaries as one option. And yet the vendor framework I use is waaaayyyy over engineered. I'm not sure who to credit for the design smell term "viscosity" meaning it's easier to do the wrong thing than the right thing in an architecture, but we got it.
 
Ranch Hand
Posts: 216
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In laymon style the ability to make change in your implementation code without breaking the code of others who use your code is key benifit of encapsulation.

Arun kumar maalik
 
reply
    Bookmark Topic Watch Topic
  • New Topic