Respuesta.

El control de acceso es un principio fundamental de la POO que asegura la encapsulación y protege los datos internos de la clase.

Historia de la pregunta:

El C++ clásico admite tres modificadores de acceso: public, protected, private. La idea surgió para proteger la implementación interna de la clase y separar la interfaz de la implementación.

Problema:

Sin un control de acceso adecuado, los usuarios de la clase pueden modificar accidentalmente el estado interno de los objetos o violar los invariantes de la clase. Un acceso mal diseñado complica el mantenimiento y la escalabilidad del código.

Solución:

Utilizar modificadores para hacer una clara separación entre lo que puede usar el mundo exterior y lo que está destinado solo a fines internos del objeto.

Ejemplo de código:

class Sample {
private:
    int secret;
protected:
    void setSecret(int s) { secret = s; }
public:
    Sample(int s) : secret(s) {}
    int getSecret() const { return secret; }
};

Características clave:

Encapsulación a través de la separación de la interfaz y la implementación.
Prevención de cambios accidentales en el estado del objeto.
Los herederos solo tienen acceso a protected (pero no a private).

Preguntas capciosas.

¿Puede una función friend o una clase friend acceder a los miembros privados de otra clase?

Sí, la palabra clave friend otorga acceso total a los miembros privados y protegidos de la clase. Este enfoque debe aplicarse con mucha precaución para no violar la encapsulación.

Ejemplo:

class PrivData {
private:
    int secret;
friend void accessSecret(const PrivData& d);
};
void accessSecret(const PrivData& d) { std::cout << d.secret; }

¿Se puede acceder a un miembro privado si se conoce su nombre, utilizando punteros o casting?

Sí, a través de casting o manipulación de memoria (por ejemplo, "trick de puntero a miembro"), pero esto viola los estándares del lenguaje y conduce a un comportamiento indefinido. No se debe hacer.

¿Qué sucede con la herencia: los miembros privados de la clase base se vuelven accesibles para el descendiente?

No, los miembros privados no son accesibles directamente para la clase derivada; el acceso solo es posible a través de métodos accesores public/protected de la clase base.

Errores típicos y anti-patrones

Abuso de miembros public y funciones friend.
Datos privados se vuelven accesibles a través de construcciones inseguras.
Ausencia de getters/setters para los datos necesarios.

Ejemplo de la vida real

Caso negativo

En un gran proyecto, todos los miembros de la clase se declararon como public para acelerar la prototipación.

Pros:

Escritura rápida del prototipo.

Contras:

Dificultad para rastrear los lugares donde cambia un estado importante, comportamiento impredecible, imposibilidad de refactorizar sin romper la interfaz.

Caso positivo

Todo está estrictamente dividido por niveles de acceso, se utilizan funciones friend solo para pruebas unitarias.