Encapsulation is a process of binding or wrapping the data and the codes that operates on the data into a single entity. This keeps the data safe from outside interface and misuse. One way to think about encapsulation is as a protective wrapper that prevents code and data from being arbitrarily accessed by other code defined outside the wrapper.
To this point, objects have been introduced as units that embody higher-level abstractions and as coherent role-players within an application. However, they couldn't be used this way without the support of various language mechanisms. Two of the most important mechanisms are:
Encapsulation, and Polymorphism.
Encapsulation keeps the implementation of an object out of its interface, and polymorphism results from giving each class its own name space. The following sections discuss each of these mechanisms in turn.
Encapsulation
To design effectively at any level of abstraction, you need to be able to leave details of implementation behind and think in terms of units that group those details under a common interface. For a programming unit to be truly effective, the barrier between interface and implementation must be absolute. The interface must encapsulate the implementation--hide it from other parts of the program. Encapsulation protects an implementation from unintended actions and inadvertent access.
In C, a function is clearly encapsulated; its implementation is inaccessible to other parts of the program and protected from whatever actions might be taken outside the body of the function. Method implementations are similarly encapsulated, but, more importantly, so are an object's instance variables. They're hidden inside the object and invisible outside it. The encapsulation of instance variables is sometimes also called information hiding.
It might seem, at first, that hiding the information in instance variables would constrain your freedom as a programmer. Actually, it gives you more room to act and frees you from constraints that might otherwise be imposed. If any part of an object's implementation could leak out and become accessible or a concern to other parts of the program, it would tie the hands both of the object's implementor and of those who would use the object. Neither could make modifications without first checking with the other.
Suppose, for example, that you're interested in the Faucet object being developed for the program that models water use and you want to incorporate it in another program you're writing. Once the interface to the object is decided, you don't have to be concerned as others work on it, fix bugs, and find better ways to implement it. You'll get the benefit of these improvements, but none of them will affect what you do in your program. Because you're depending solely on the interface, nothing they do can break your code. Your program is insulated from the object's implementation.
Moreover, although those implementing the Faucet object would be interested in how you're using the class and might try to make sure that it meet your needs, they don't have to be concerned with the way you're writing your code. Nothing you do can touch the implementation of the object or limit their freedom to make changes in future releases. The implementation is insulated from anything that you or other users of the object might do.
Above answer was rated as good by the following members: SagarSonawane
To this point objects have been introduced as units that embody higher-level abstractions and as coherent role-players within an application. However they couldn't be used this way without the support of various language mechanisms. Two of the most important mechanisms are:
Encapsulation and Polymorphism.
Encapsulation keeps the implementation of an object out of its interface and polymorphism results from giving each class its own name space. The following sections discuss each of these mechanisms in turn.
Encapsulation
To design effectively at any level of abstraction you need to be able to leave details of implementation behind and think in terms of units that group those details under a common interface. For a programming unit to be truly effective the barrier between interface and implementation must be absolute. The interface must encapsulate the implementation--hide it from other parts of the program. Encapsulation protects an implementation from unintended actions and inadvertent access.
In C a function is clearly encapsulated; its implementation is inaccessible to other parts of the program and protected from whatever actions might be taken outside the body of the function. Method implementations are similarly encapsulated but more importantly so are an object's instance variables. They're hidden inside the object and invisible outside it. The encapsulation of instance variables is sometimes also called information hiding.
It might seem at first that hiding the information in instance variables would constrain your freedom as a programmer. Actually it gives you more room to act and frees you from constraints that might otherwise be imposed. If any part of an object's implementation could leak out and become accessible or a concern to other parts of the program it would tie the hands both of the object's implementor and of those who would use the object. Neither could make modifications without first checking with the other.
Suppose for example that you're interested in the Faucet object being developed for the program that models water use and you want to incorporate it in another program you're writing. Once the interface to the object is decided you don't have to be concerned as others work on it fix bugs and find better ways to implement it. You'll get the benefit of these improvements but none of them will affect what you do in your program. Because you're depending solely on the interface nothing they do can break your code. Your program is insulated from the object's implementation.
Moreover although those implementing the Faucet object would be interested in how you're using the class and might try to make sure that it meet your needs they don't have to be concerned with the way you're writing your code. Nothing you do can touch the implementation of the object or limit their freedom to make changes in future releases. The implementation is insulated from anything that you or other users of the object might do.
storing the data and a function in a single class is know as encapusulation.data cannot be accessible to the outside world and only those fuctions which are stored in the class can access it.
THE SINGLE MOST IMPORTANT FACTOR THAT DISTINGUISHES A WELL DESIGNED MODULE FROM A POORLY DESIGNED ON IS THE DEGREE TO WHICH THE MODULE HIDES ITS INTERNAL DATA AND OTHER IMPLEMENTAION DETAIL FROM OTHER MODULES.
A WELL DESIGNED MODULE HIDES ALL OF ITS IMPLEMENTAION DETAILS CLEANLY SEPARATIONG ITS API FROM ITS IMPLEMENTAION.
AND INFORMATION HIDING OR ENCAPSULATION IS THE BEST WAY TO SEPRATE OUT DIFFERENT MODULE.
SO THIS PEOMOTE THE MODULER DEVELOPEMENT OF ANY PROJECT.
Encapsulation is a process of binding or wrapping the data and the codes that operates on the data into a single entity. This keeps the data safe from outside interface and misuse. One way to think about encapsulation is as a protective wrapper that prevents code and data from being arbitrarily accessed by other code defined outside the wrapper.
Automatic Transmission on an automobile. It encapsulates 100's of bits of information about your engine such as how much are accelerating the pitch of the surface you are on and the position of the shift lever. You as a user have only one method of affecting this complex excapsulation: by moving the gear-shift lever. You can't affect the transmission by using the turn signal or windshield wipers for example. Thus the gear-shift lever is a well-defined(Indeed Unique) interface to the transmission. Further what occurs inside the transmission does not affect objects outside the transmission. eg Shifting gear does not switch on head lights! coz an automatic transmission is encapsulated dozens of car manufacturer's can implement one in anyway they please.
1 
0