''Why exactly are private variables supposedly better than public variables??''

The rule is not "keep all variables private" it's "don't make primitive 
things globally public". Encapsulation is hierarchical, and many classes 
with public variable should exist nested inside larger classes that then 
keep them private. Consider a 'string' class and the copy-on-write string 
data structure hidden inside it. That should have "public" variables, but 
the structure itself should be private to the string.

''Much the same reason as a CD player usually has a couple of big buttons and switches on the front, which are documented in a manual, and the interesting electronics are all inside where you can't get at them. --Harri''

Yep. And inside that CD player are gadgets made by subcontractors - 
transformer, laser, oscillator, etc. They plug into each other using 
standardized connectors, but each one also has private elements they keep 
secret from each other and from the CD player assembly company.

''1.  Because it helps people know how to use a product, if the stuff they don't need and shouldn't touch isn't mixed in with the important bits. Usually the data is not relevant, only a few operations which you can perform on the data.''

This also implies style issues, such as all public methods should be at the 
top of a class, and the privates at the bottom, so readers don't have to 
scroll before getting what they need.

''2.  Because you don't want to field support calls from people who broke your product by playing with its insides.''

Including support calls from yourself.

''3. Because you want to be able to bring out Product Version 2, with the same buttons on the front, but with the electronics changed, and nobody should notice the difference.''

And because you want the one version of the product to internally use 
Derived Class number 2 instead of number 1, like a drill can change its 
bit. Polymorphism needs the LiskovSubstitutionPrinciple to work cleanly, 
and this needs language support in the form of interfaces and encapsulation. --PhlIp

''No, a language does not require support for "interfaces and encapsulation" to provide for sound, hierarchical, encapsulated code. You are assuming too much when you assume FunctionPointersInaCeeStructStyleOop (that is, C++, Java, Ruby, Python, etc.).'' --CraigEverett

----

I would strongly argue in favor of "keep all variables private."  Having class variables modified by both a base and derived class is often a sign of a bad class hierarchy.  Neither the base nor derived class is fully responsible for the data and confusion reigns.  Do all of the accesses to a variable within a single class and you will simplify your software.  -- WayneMack

Here's the string example:

	class String {
		struct Storage {
			char  *string;
			int    referenceCount;
		};
		...
	};

Storage is not a base class. It's an implementation detail of String. --PhlIp

Are there AlternativesToHierarchicalEncapsulation? Can we make the concept of classes distinct from interfaces?

---------
'''See Also:''' LawOfDemeter, EncapsulationDefinition, TreeOrientedPerspective