I am just starting to learn about encapsulation, and I stumbled upon two functions used by std::string that seems to break its encapsulation.
Regarding c_str() and data() from http://www.cplusplus.com/reference/string/string/c_str/ and http://www.cplusplus.com/reference/string/string/data/
"The pointer returned points to the internal array currently used by the string object to store the characters that conform its value".
For someone just learning about OO programming, is it ever a good idea to break encapsulation? How about for someone who is more advanced?
As an aside, it seems like this is different behavior from C++98. Why do you believe that they made these changes?
Thanks for your time.
I stumbled upon two functions used by std::string that seem to break its encapsulation.
Your examples are not violations of the rules on encapsulation:
The C++ Programming Language, Fourth Edition, Bjarne Stroustrup:
!2.5. Pointer to Function
There is no implicit conversion of a string to a char*. That was tried in many places and found to be error-prone. Instead, the standard library provides the explicit conversion function c_str() to const char*.
The same is applicable to string::data(). What that means is that the STL has given you a discreet, read-only interface through which to extract the data stored within a std::string. That is not a violation of encapsulation - the internal data remains hidden behind a discreet interface and cannot be modified. A violation of encapsulation would be if the internal array of char stored within the string object was directly exposed for manipulation by making it public, or part of the global namespace, or through an implicit conversion of a string to a char* and vice versa.
Having said that:
Is it ever a good idea to break encapsulation?
It is never a good idea to follow any programming model religiously, if your goal is to create working applications in the real world.
Consider every programming "rule" laid out by every programming paradigm and model and approach, etc etc, as a guideline, a best practice, once you leave the classroom.
Extreme Example: You have deployed a complex application into production, and a bug surfaces. You have one hour to fix the bug, or you lose your job and your firm loses a client. (Yes, such situations do occur - been there, done that...). You can put in a quick fix that will violate the rules of encapsulation, but will have your system up and running again in half an hour. Or, to abide by the rules of encapsulation, you can take two days to refactor your application, carefully modify 500 lines of code, deploy the new version to your test group and hopefully have a patched version ready in two weeks. What to do?
The answer is quite clear: For the moment at least, you're going to break the rules of encapsulation, put in that quick and dirty fix, and get your system up and running again.
Once that's taken care of, you can sit down, think things through, discuss it with your co-workers and managers, and decide if there is indeed a significant ROI in taking out the two weeks to maintain the rules of encapsulation.
You can be sure of one thing: If you're working in a business environment and people are making their living by delivering working software, the decision will not be dictated by the rules of OOP outlined in some textbook, but by the business's bottom line.