You have to recompile client code if you change private inner things of the called code.
No. You likely have to because of poor (or non-existent) design for maintaining binary compatibility. For example, create a shared object using a proper API (encapsulation, no inlines, pimpl, high cohesion, loose coupling) and change its implementation without changing the interface itself. You will not have to recompile client code at all.
The problem I see with this thead is that many of these concepts all work together. Following best practices, using encapsulation, etc.. all go hand-in-hand or any of them can be discredited.
Time and time again I read/hear things like, "A stuct should be used denote intent to represent a collection of public data and nothing more." All I can think is, "No!" In C++, there should be no such thing as a purposefully poorly-designed object (which is exactly what this object would be).
Encapsulation in itself basically tells you what the definition is. Encapsulation is nothing more than a fancy way of saying data hiding when it comes to OOD/OOP. It means that all of the object's data is contained and hidden in the object and access to it restricted to members of that class.
It means that all of the object's data is contained and hidden in the object and access to it restricted to members of that class.
Agreed, but C++ doesn't provide that fully. Private section is a part of object ABI.
For example, create a shared object using a proper API (encapsulation, no inlines, pimpl, high cohesion, loose coupling) and change its implementation without changing the interface itself. You will not have to recompile client code at all.
This means you have to provide encapsulation manually, and *you* are responsible for it, not the langauge. Also keep in mind, pimpl slows down object construction / destruction. Well it is like saying you can do OOP in C, by function pointer magic to implement vtables. Albeit possible, it dosn't make C an OO language.
Contrary, in Java/C# if I write "private", I know it is definitely private. No code external to the class ever relies on the content of the private section, unless explicitly told to. In C++, all client code using the class, relies on the content of the private section. That is why it has to be in the header file.
From what I know, FQA does not state that client code must be recompiled each time you change the implementation. It states that client code must be recompiled each time you change the implementation if your interface has a form of class definitions with private sections. This shows how useless the private keyword is. I don't see how your examples disprove this statement.
Yes, I understand it, and I agree that this technique (or one of a few dozens different ones) solves the issue. But it also shows the problem with private - if you use it in a straightforward, intended way, you're doing it wrong. So private doesn't help, nor is necessary to achieve encapsulation (at least to the point possible in non-managed environments).
But it also shows the problem with private - if you use it in a straightforward, intended way, you're doing it wrong.
it's not a problem with private, it's a problem with erroneous expectations. Encapsulation can be achieved through data hiding, but it does not need to be, and it is not in C++. Thinking private is for that is like thinking that volatile is for multithreading.
If you actually need a compilation firewall, then yes, a pointer (or, rather, unique_ptr these days) to some sort of implementation object holding all private and nonvirtual (but not protected) members is typically used. But not a whole lot of problem sets actually benefit from this.
There are plenty of reasons to use encapsulation (private access specifiers for members) over an everything-is-public-like-in-C struct. Pursuing binary compatibility is only a single one of the benefits.
Yes, if you change the API, you have broken binary compatibility.
And that is bad, too. In Java/C# and many other languages I can freely change public API without breaking binary compatibility. I just have to be careful not to modify or remove anything that was used, but I can add new things.