Encapsulation
 

I really not sure what encapsulate means. As I understand that when data is encapsulate that means that data is hidden(like private) .. Right?

Yeah,

I believe that Encapsulation is when you design your objects to through interfaces (not to be confused with an interface Object which is entirely different). By that I mean writing your objects so that all data (aka fields) is private or protected, and you acces them only through accessor and mutator methods (e.g. "get" and "set" methods) which are public.

-cludwin

I never really got into the theory behind encapsulating, but I did read this story in Linux Format a few months back:

Imagine an office worker writes a letter to a client and puts it in an envelope. S/he then gives this envelope to his/her secretary who puts it into the post. This then gets sent to the postal service, where it is sent to the client. The client's secretary puts it onto the client's desk, without opening or reading it. This is encapsulation.

Basically, the secretary doesn't know what's in the envelope, only that envelopes are to go in the mail. The client's secretary doesn't know what's in the envelope, only that it has to be put on his/her bosses desk. The client doesn't know what's in the envelope until s/he opens it.

Or, to be more technical:

Some data (the letter) is hidden inside of some other data (the envelope). This other data (the envelope) is of a recognised type that has to be sent by a specific method (the postal service). Once the data reaches its target (the client) it needs to be unencapsulated (opened) so that it (the letter) can be read by the appropriate program.

There are various reasons for encapsulation. I would like to just mention one that springs to mind. I have found that encapsulating data in my objects has generally led to my programs being much easier to debug.

eg, if a data member is private, and only acessable thru set or get methods, then if that piece of data is somehow getting a 'troublesome' or 'wrong' value at some point, i can always go straight to the set() method to deal with the problem......eg make sure the value is never set above or below certain values. If the data member had been public, then the problem could be occuring anywhere throughout the program.

Ive pretty much typed this answer off the top of my head, and its only one example, but you get the idea. (?)

Doing a Comp.sci. degree with Java as the programming langauge of choice, you get used to hearing these buzzwords.
Encapsulation leads to code that produces easily maintainable and re-usuable objects.
To highlight this, they made us make a "Person" class that would hold just a few details like the persons name in the beginning of the year. Later on in the year, they made us use that "Person" again, but extend it to student, so that it contained details like student number etc. Then they made us use the Person class to make a customer object in another object.
It was a good excersise, and highlited the benefits of OO, and usefulness of encapsulating objects.


glj

the java tutorial
 

There is some good info about OOP here:

http://java.sun.com/docs/books/tutor...ts/object.html


Have you heard about AOP yet? It is a nice complement to OOP that makes it possible to have better modularity in complex OO programs. It works because of a technique called "dependency reversal."

Find out more about AOP here:
http://jac.aopsys.com/doc/introduction.html
http://aosd.net/