Data Encapsulation
Let us assume that you have created a new library that you want to distribute to other programmers. For example, working with images (bmp, gif or jpg) isn’t that easy in C++. You have to write methods (functions) for reading an image, identifying what type it is, displaying the image etc. There are many image-processing applications where the first step is to read an image. The simplest application is Optical Character Recognition (OCR). In OCR we write a program that will be able to recognize hand-written letters or numbers. For instance, if you write 8, the computer should be able to recognize that an 8 has been written (no matter how bad the handwriting is). Whatever you write on paper will be scanned into the system and stored in the form of an image file. A programmer developing an OCR application could either start from scratch or he could focus on his problem (i.e. OCR).
By starting from scratch, he has to write a lot of coding just for the purpose of reading an image. Instead if he can get access to some good Image processing library (which will contain files for reading images), he could simply use the #include directive and concentrate on the OCR algorithm.
So, let’s say that you have created a library for the purpose of image processing. You will make use of the concept of classes. You will create a class called ‘Image’, which contains member functions for reading an image, identifying the type of image etc. You will also have some member data like the height and width of the image. When you distribute your library to others, you give them the opportunity to create objects (or instances) of your ‘Image’ class. You will also have provided a little help file describing the various functions that are available for use. Note: You will only describe the use of the various functions (ex: the function syntax and what it will do). You will not be providing an insight into the implementation aspect of the function (i.e. you will not be explaining the function definition).
Now, the OCR person will start coding his application. There is a chance that he might use the same member data identifier ‘length’ and ‘width’ in his program. Imagine the consequence if ‘length’ and ‘width’ are not made private within your class. There is a good chance that the user will fiddle around with the data (knowingly or unknowingly) and their values will get altered by the user (which is what you don’t want). The result is that your functions, which operate on these member data, will produce some ambiguous results. By hiding your data, you prevent such problems from happening because the user will never be able to access or modify your class’ private members.
The idea of encapsulation is to prevent users from having access to everything. They should be able to access members that are needed for their use. In larger classes there may be many members (data and functions) which are not required for someone who is going to use your class. These members should be made private.
Remember: Usually the class declarations are written in a *.h header file (this is called as the interface) while the definitions for the member functions are written in a *.cpp source file (this will be the implementation). Thus even if the implementation is changed the interface remains unaffected (more about this in Multiple file programming).
Thus to summarize:
Data encapsulation means hiding the implementation of a class from the user. We restrict the user in such a way that the user can perform only limited operations on the private part (and that is only through the member functions). The user cannot access any of your private members directly.
Another advantage of hiding the implementation is that you (the class designer) may decide to change the process of implementation. You might have discovered some better and effective method for doing the same purpose. By hiding the implementation, all you need to do is to change the function definition. The user will never have to change his code (because you have only changed the implementation, which the user has nothing to do with). The code written by the user will still run even though you have changed the implementation.
Copyright © 2004 Sethu Subramanian All rights reserved.