What is encapsulation?

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!

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.

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.

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.

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.

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.

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.?

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?

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.

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.

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