Where the c plus plus encapsulation done?

Answer 1

There are no statements as such. Encapsulation is a design concept. The basic principal of encapsulation is that an object should contain all the information necessary to use the object, nothing more and nothing less. In other words, an object is a self-contained entity.

Answer 2

You cannot actually circumvent encapsulation, you can only undermine it with poor design. Undermining encapsulation simply means that any encapsulation you intended cannot be enforced by the compiler because you haven't encapsulated your members correctly. Unlike the real world where encapsulation can often be easily circumvented (lock-picking, reverse-engineering, etc), class design can enforce strict encapsulation wherever it is required. But if you write sloppy code, you undermine any encapsulation you intended, and errant code can easily slip through the net.

Consider the following class:

struct bad

{

bad(): m_data(1) {}

void set_data(unsigned int data){ if(data) m_data=data; }

unsigned int m_data;

};

In the above example, the mutator, set_data(), acts as a gatekeeper, ensuring that m_data is always non-zero (the constructor ensures it is initialised to 1). But because this class is a struct, m_data is implicitly public, thus the encapsulation implied by set_data is completely undermined. Any code can therefore legitimately assign the value 0 directly to bad::m_data. It is not circumventing the encapsulation because, logically, there is no encapsulation to circumvent.

To rectify this problem, m_data must be declared private, as in the following:

struct good

{

good(): m_data(1) {}

void set_data(unsigned int data){ if(data) m_data=data; }

private:

unsigned int m_data;

};

Now it is impossible to circumvent set_data(). Encapsulation is now assured.

You will often hear it said that friend functions can undermine encapsulation, but this is, frankly, errant nonsense. Yes, friend functions do have unrestricted access to private members, and yes, they can circumvent even the most stringent encapsulation. But the same can be said of any member of the class. Friends are not members, but if a class allows an external function to gain private access, then that friend must follow the exact same rules of encapsulation as the members of the class itself -- otherwise it is distinctly un-friendly. And since you would never allow private access to code you have no control over, it's up to you to enforce the encapsulation in your own friend functions, just as it is up to you to ensure that your class members maintain encapsulation. Remember that encapsulation only exists from outside of the class interface, and that a friend is simply an extension of that same interface. External code (non friend functions) are forced to use the interface you provide, but they cannot circumvent the encapsulation that you yourself put in place, both within the class itself and within the friend function.

Protected access is always something to be wary of, as this can easily undermine encapsulation just as public access can. This is because you have no control over how other programmers might abuse the privilege when they derive new objects from your classes. Best practice dictates that private member variables should never be declared protected. Only private methods should be declared protected, and only when it is necessary for a derived class to be able to call those methods. This forces your derivatives to use the encapsulation provided by the public and protected interface. As the old saying goes, keep your powder dry; and keep your private member variables private.

Remember that no-one can circumvent encapsulation. If they can, then there simply is no encapsulation to begin with.

Answer 3

Encapsulation is achieved through classes, where member data is declared private and made accessible outside of the class via the public and/or protected interfaces. Only the class itself and friends of the class have access to the private representation. Protected methods are the same as private methods but are also accessible to derived classes and their friends. Public methods are accessible to any code.

Friends are functions that require access to the private representation of a class but are not themselves members of the class. This could be because they are members of another class entirely or because they operate upon two or more classes but cannot be considered a member of any of them. However, because friend functions are declared by the class upon which they operate, they are as much a part of that class interface as any other member would be.