Propósito de los miembros privados en una clase

Es posible que desee leer el tema Ocultar información en wikipedia.

Esencialmente, los miembros privados permiten que una clase oculte sus detalles de implementación de los consumidores externos. Esto permite a una clase controlar mejor cómo se expresarán los datos y el comportamiento de ti, y permite al consumidor ignorar detalles que no son relevantes para el propósito principal de la clase.

Ocultar detalles de implementación mejora la capacidad de mantenimiento de un program evitando que el código externo de la clase establezca dependencias sobre esos detalles. Esto permite que la implementación cambie independientemente de los consumidores externos, con un riesgo reducido de romper el comportamiento existente. Cuando los detalles de la implementación privada se hacen públicos, no se pueden cambiar sin la posibilidad de romper con los consumidores de la clase que dependen de esos detalles.

Los miembros privados también permiten que una clase proteja su implementación de abuso. Típicamente, el estado de una clase tiene dependencias internas que definen cuando el estado es válido - y cuando no lo es. Podemos considerar que las reglas que gobiernan la validez de la información de estado son invariantes, lo que significa que la clase siempre espera que sean verdaderas. Exponer detalles privados, permite que el código externo modifique este estado de una manera que puede violar los invariantes, y por lo tanto comprometer la validez (y el comportamiento) de la clase.

Un adicional el beneficio de ocultar información, es que reduce el área de superficie que los consumidores de la clase tienen que entender con el fin de interactuar adecuadamente con la clase. La simplificación es generalmente algo bueno. Permite a los consumidores centrarse en la comprensión de la interfaz pública, y no en cómo la clase logra su funcionalidad.

Muy bien explicado en Sección 7.4: Proteja sus Partes privadas de este tutorial en línea de C++ .

¿Por qué molestarse con estas cosas?

Los especificadores permiten que una clase sea muy complejo, con muchas funciones de miembro y los miembros de datos, mientras que tiene un interfaz pública simple que otros las clases pueden usar. Una clase que tiene dos cien miembros de datos y cien las funciones miembro pueden ser muy complicado de escribir; pero si hay sólo tres o cuatro miembros públicos funciones, y el resto son todos privado, puede ser fácil para alguien aprende a usar la clase. Él sólo necesita entender cómo usar un pequeño un puñado de funciones públicas, y no necesita molestarse con los dos cientos de miembros de data, porque no es se le permite acceder a estos datos. Él puede acceder únicamente a los datos privados a través de la interfaz pública de la clase. Sin duda, en un pequeño programa, utilizando estos los especificadores pueden parecer innecesarios. Sin embargo, vale la pena entender si usted planea hacer cualquier programa de tamaño razonable (más de un par cien líneas). En general, es bueno practique para que los miembros de datos sean privados. Funciones miembro que deben ser llamadas desde fuera de la clase debe ser público, y las funciones de los miembros que son solo se llama desde dentro de la clase (también conocido como "funciones auxiliares") probablemente debería ser privado. Estos especificadores son especialmente útiles en un programa grande que involucra a más de un programador.

La explicación anterior explica cómo usar private facilita la curva de aprendizaje. Aquí hay un ejemplo que explica el aspecto de "ruptura de código":

Aquí hay una clase ParameterIO que lee y escribe un vector de parámetros enteros

class ParameterIO
{
public:
    // Main member
    vector<int> *Params;
    string param_path;

    // Generate path
    void GeneratePath()
    {       
        char szPath[MAX_PATH];
        sprintf(szPath,"params_%d.dat",Params->size());
        param_path = szPath;
    }

    // Write to file
    void WriteParams()
    {
        assert_this(!Params->empty(),"Parameter vector is empty!");
        ofstream fout(param_path.c_str());
        assert_this(!fout.fail(),"Unable to open file for writing ...");
        copy(Params->begin(),Params->end(),ostream_iterator<int>(fout,"\n"));
        fout.close();
    }

    // Read parameters
    void ReadParams(const size_t Param_Size)
    {
        // Get the path
        Params->resize(Param_Size);
        GeneratePath();
        // Read
        ifstream fin(param_path.c_str());
        assert_this(!fin.fail(),"Unable to open file for reading ...");
        // Temporary integer
        for(size_t i = 0; i < Params->size() && !fin.eof() ; ++i) fin>>(*Params)[i];
        fin.close();
    }

    // Constructor
    ParameterIO(vector<int> * params):Params(params)
    {
        GeneratePath();
    }

    // Destructor
    ~ParameterIO()
    {
    }      

    // Assert
    void assert_this(const bool assertion, string msg)
    {
        if(assertion == false) 
        {
            cout<<msg<<endl;
            exit(1);
        }
    }
};

El siguiente código rompe esta clase:

const size_t len = 20;
vector<int> dummy(len);
for(size_t i = 0; i < len; ++i) dummy[i] = static_cast<int>(i);
ParameterIO writer(&dummy);

// ParameterIO breaks here!
// param_path should be private because 
    // the design of ParameterIO requires a standardized path
writer.param_path = "my_cool_path.dat";
// Write parameters to custom path
writer.WriteParams();

vector<int> dunce;
ParameterIO reader(&dunce);
// There is no such file!
reader.ReadParams(len);

Metafóricamente, exponer a los miembros privados como públicos es como tener una opción en el salpicadero de su automóvil que le permite ajustar la presión del aceite del motor.

El coche debe gestionar eso internamente (en privado), y el usuario debe estar protegido de jugar con él directamente (encapsulación), por razones obvias.

Realmente depende de tu ideología. La idea es ocultar información que no debería ser expuesta por alguna razón.

Si tiene una biblioteca que desea publicar en línea, mucha gente la descargará y algunos pueden usarla en su código. Si mantiene su API pública al mínimo y oculta los detalles de la implementación, tendrá menos dificultades para actualizarla cuando encuentre errores o desee mejorar el código.

Además, en Java, por ejemplo, no tiene forma de restringir el acceso a una variable miembro sin cambiar su visibilidad, por lo que a menudo te encuentras prematuramente creando getters y setters y haciendo que la variable en sí sea privada o protegida. En Python, por ejemplo, ese problema no existe porque puedes hacer que los getters y setters se comporten como variables para el acceso directo (se llaman propiedades allí).

Por último, a veces es necesario tener métodos que requieren un estado consistente para ser útil y daría lugar a problemas si se accede directamente.

Una regla general es: si expones algo, alguien lo usará. Y la mayoría de las veces lo usarán por las razones incorrectas (es decir, no cómo pretendías que se usaran). En este caso, la ocultación de información es el equivalente a las cerraduras para niños en los gabinetes de armas.

Para agregar a la respuesta de Peter, digamos que su clase almacena un nombre, y desea cambiarlo de usar una sola cadena de nombre a una cadena de nombre y una cadena de apellido. Si sus miembros fueran públicos, otras clases podrían leer (o escribir) la variable name directamente, y se romperían cuando esa variable desapareciera.

Sin mencionar que es posible que no desee que otras clases tengan la capacidad de editar sus miembros en absoluto.

A veces no quieres revelar información privada a todo el mundo. Por ejemplo, no desea que su edad sea conocida por el público, pero es posible que desee decirle a la gente si tiene más de 25 años.

¿Cuáles son los propósitos de tener órganos internos en el cuerpo humano? ¿Qué hay de malo en tener todos los órganos afuera?

¡Exactamente!

La respuesta corta sería: Porque los necesitas para no poder vivir sin ellos y no puedes exponerlos a todo el mundo para modificarlos y jugar con ellos porque eso podría matarte (hacer que tu clase no funcione correctamente).

Ningún daño en absoluto dependiendo de la audiencia y el consumo de la clase. Permítanme repetirlo una vez más para que se hunda.

Ningún daño en absoluto dependiendo de la audiencia y el consumo de la clase.

Para muchos proyectos pequeños de una o dos personas que toman un mes más o menos, conseguir todas las definiciones privadas y públicas perfectamente podría aumentar la carga de trabajo sustancialmente. En grandes proyectos, sin embargo, donde puede haber varios equipos y los equipos no están geográficamente ubicados juntos, obtener el diseño correcto de todas las interfaces públicas desde el principio puede aumentar en gran medida la probabilidad de éxito del proyecto en general.

Así que realmente tienes que mirar cómo va a ser consumida una clase y por quién antes de que puedas siquiera comenzar a responder esta pregunta. Del mismo modo, ¿cuánto tiempo va a ser el ciclo de vida del desarrollo de software? ¿Son meses? Años? Décadas? ¿Habrá otras personas además de ti usando la clase?

Cuanto más "público" la clase (es decir, cuantas más personas consuman y usen la clase), más importante es clavar una interfaz pública sólida y adherirse a ella.

Un breve ejemplo: Es posible que deba asegurarse de ciertas condiciones en ese valor. En este caso, configurarlo directamente puede romper tal condición.

Muchas personas argumentan como "puede que no quieras que todo el mundo lo lea", pero creo que la restricción de establecer un valor es un ejemplo más útil.