У меня есть два вопроса, которые нужно задать и получить разрешение (от Учебник по С++):
1: Class internals are protected from inadvertent user-level errors, which might corrupt the state of the object.
2: The class implementation may evolve over time in response to changing requirements or bug reports without requiring change in user-level code.
Теперь, во-первых, я могу подумать о cin или любом другом объекте ввода-вывода, состояние которого может быть повреждено из-за неверных данных, но все же я не понимаю, как класс внутренняя защищенная. Второй пункт мне совершенно непонятен.





Каждый класс (за редким исключением) имеет открытый интерфейс и закрытую реализацию.
Это позволяет менять реализацию без изменения открытого интерфейса.
Таким образом, пользователям класса не нужно будет менять свой код при изменении реализации.
И относительно стандартного класса std::cin тогда он не поврежден, если пользователь ввел неверные данные. Его внутреннее состояние стабильно. Он просто устанавливает для пользователей флаг ошибки, чтобы сообщить им, что они делают что-то не так.
Дело в том, что любой доступ к объекту должен проходить через общедоступный интерфейс, который должен быть определен безопасным способом (представьте, что это своего рода брандмауэр для внутренних компонентов объекта).
Это аспект дизайна. У объектов должны быть четко определенные роли (предоставленные через общедоступный интерфейс). Эти роли редко (если вообще) должны меняться в ходе эволюции программного обеспечения. Внутренняя реализация может измениться по разным причинам (ошибки/оптимизация/и т.д.), но пока интерфейс остается неизменным, программное обеспечение должно продолжать работать без необходимости изменения других модулей. Инкапсуляция — отличный способ сделать программное обеспечение модульным.
Оператор использует «искажать состояние» в очень общем смысле, когда значения переменных-членов отклоняются от ожиданий использующих их методов. Рассмотрим переменную-член, которая не является общедоступной: вы устанавливаете ее в конструкторе и изменяете ее в функциях-членах. Следовательно, какое бы значение ни имела переменная-член, оно было присвоено только вашим кодом. Предполагая, что ваш код правильный, состояние переменной всегда будет таким, каким его ожидает ваш код. С другой стороны, общедоступные переменные-члены могут быть изменены кодом, который использует ваш класс. Каждый раз, когда ваш код ссылается на такую переменную, он рискует найти значение, установленное чужим кодом. В ситуациях, когда не все возможные значения считаются правильными, ваши функции-члены должны предполагать, что значение в общедоступной переменной-члене недопустимо.
Это способ сказать, что если вы решите изменить значение переменной-члена, заменить ее новыми переменными-членами или удалить ее из реализации, вы можете сделать это только до тех пор, пока переменная является закрытой. Публичные переменные-члены не обеспечивают такой защиты, потому что, если вы переименуете или удалите их, внешний код, который их использует, перестанет компилироваться. Еще хуже ситуация бывает, когда вы решаете изменить значение переменной, не переименовывая ее. В таких случаях внешний код все равно будет компилироваться, но ваш код окажется в поврежденном состоянии, как описано в пункте 1 выше.
Re: #2: внешний код, который их использует, перестает компилироваться - это лучший вариант. Часто он все еще может компилироваться, но появляются более тонкие ошибки.