¿Estas dos clases violan la encapsulación?

Question

class X 
{ 
protected: 
    void protectedFunction() { cout << "I am protected" ; } 
}; 

class Y : public X 
{ 
public: 
    using X::protectedFunction; 
}; 

int main() 
{ 
    Y y1; 
    y1.protectedFunction(); 
} 

De esta manera puedo exponer una de las funciones de la clase base.

1. ¿Esto no viola el principio de encapsulación?
2. ¿Hay alguna razón específica por la cual esto se encuentra en la norma?
3. ¿Hay algún uso de esto, o se va a cambiar en el nuevo estándar?
4. ¿Hay algún problema abierto relacionado con esto en la norma?

Answer 1

Sí, y por eso protected ha recibido una buena cantidad de críticas.

Bjarne Stroustrup, el creador de C++, lamenta esta en su excelente libro El diseño y evolución de C++:

Una de mis preocupaciones acerca protegida es exactamente que hace que sea muy fácil uso de una base común la forma en que se podría datos globales descuidadamente han utilizado .... En retrospectiva, creo que es protegida un caso en "buenos" y los argumentos la moda han vencido mi mejor juicio y mis reglas de oro para la aceptación de nuevos caracteristicas.

Answer 2

Lo has hecho por ti mismo.
Se puede escribir

class Y : public X 
{ 
public: 
    void doA() 
    { 
     protectedFunction(); 
    } 
}; 

int main() 
{ 
    Y y1; 
    y1.doA(); 
} 

no veo ninguna razón para preocuparse por ello.
Las funciones protegidas son piezas de lógica reutilizable en el árbol de herencia. Puede ocultarlos si hay alguna lógica o restricción interna o, como en su caso, puede exponerlo si está seguro de que esto no dañará a nadie.

Answer 3

Creo que fue el propio Stroustrup quien dijo que las características de encapsulación e integridad de datos integradas en C++ están diseñadas para mantener a las personas honestas honestas, no para detener a los delincuentes.

Answer 4

No. protectedFunction() está protegido. Puede llamarlo desde clases derivadas, por lo que podría haberlo llamado directamente desde un miembro público de Y, y llamar a este miembro público desde main().

Si usted podría haber hecho eso con un método privado, no habría sido un problema ... (Editado para ser un poco más claro).

Answer 5

El diseñador de clases debe saber que declarar una función o variable miembro (aunque todas las variables deben ser privadas, realmente) como protegidas es casi lo mismo que declararla pública (como demostró que es fácil acceder a cosas protegidas). Teniendo esto en cuenta, tenga cuidado al implementar esas funciones en la clase base para dar cuenta del uso "inesperado". No es una violación de la encapsulación porque puede acceder a ella y exponerla.

protected es solo una manera más complicada de declarar algo público.

Answer 6

Desde el punto de vista del lenguaje, que no es más de una violación de la encapsulación de crear un método delegado en el objeto derivado:

class Y : public X 
{ 
public: 
    void protectedFunction() { 
     X::protectedFunction(); 
    } 
}; 

Una vez que se protege un método, se ofrece a las clases que se derivan para hacer con él como lo deseen. La intención de la declaración using no cambiaba el acceso a métodos heredados, sino que evitaba problemas con la ocultación de métodos (donde un método público en X estaría oculto en el tipo Y si se define una sobrecarga diferente).

Ahora, es un hecho que debido a las reglas del lenguaje se puede usar para cambiar el nivel de acceso para los métodos 'usados' como en su ejemplo, pero eso realmente no abre ningún agujero en el sistema. Al final, las clases derivadas no pueden hacer nada más que lo que podían hacer antes.

Si la pregunta real es si el uso particular es una violación de la encapsulación desde un punto de vista de diseño (donde el diseño aquí es diseño de aplicación, no de lenguaje), entonces muy probablemente sí. Exactamente de la misma manera que hacer públicos los datos o métodos internos. Si ha sido diseñado para ser protegida por el diseñador inicial de X, entonces es probable que Y implementador no quería que fuera público ... (u ofrecer un método de delegación para el mismo propósito)

Answer 7

Nº

Para utilizar el método público que debe tener una instancia de Y esto no funcionará:

int main() 
{ 
    X y1; 
    y1.protectedFunction(); 
} 

Si Y en su nueva definición expone una nueva interfaz que depende de la Y. X sigue estando protegida.

Answer 8

En C++ incluso el modificador privado no garantiza la encapsulación. Nadie puede evitar que te pegues un tiro en el pie.

Herb Sutter en su artículo "Uses and Abuses of Access Rights" muestra diferentes maneras de cómo se puede "romper la encapsulación".

Aquí un ejemplo divertido del artículo de Herb.

Mal macro magia

#define protected public // illegal 
#include "X.h" 
//... 
X y1; 
y1.protectedFunction(); 

Answer 9

No, realmente no veo el problema.

En lugar de using, que podría haber hecho esto:

class X 
{ 
protected: 
    void protectedFunction() { cout << "i am protected" ; } 
}; 

class Y : public X 
{ 
public: 
    void protectedFunction() { X::protectedFunction(); } 
}; 

Cualquier clase puede tomar cualquier miembro que es visible a ella, y decide exponerlo públicamente. Puede ser un mal diseño de clase para hacerlo, pero ciertamente no es un defecto en el lenguaje. Todo el punto en los miembros privados o protegidos es que la clase misma debe decidir quién debe tener acceso al miembro. Y si la clase decide "Voy a dar acceso a todo el mundo", entonces así es como está diseñada la clase.

Si seguimos su lógica, entonces getter y setters violan la encapsulación también. Y a veces lo hacen. Pero no porque el lenguaje esté roto. Simplemente porque estás eligiendo diseñar clases rotas.

Al hacer que un miembro sea protegido, le da a las clases derivadas la libertad de hacer haciendo que les guste con el miembro. Pueden verlo, para poder modificarlo o exponerlo públicamente. Eligió hacer esto posible cuando hizo que el miembro estuviera protegido. Si no quieres eso, deberías haberlo hecho en privado.

Answer 10

Personalmente, creo que esta pregunta debería responderse más como una cuestión de diseño que como una cuestión tecnológica.

Me gustaría preguntar: "¿Cuál era el objetivo del método protegido en primer lugar?" ¿Era un método que solo deberían llamar las subclases, o es un método que las subclases deben anular? Sin embargo, puede ser un método que no se espera en una clase base genérica, pero que quizás se espera en una subclase. Para el cliente de la clase base nunca supieron acerca de ese método protegido. El creador de la subclase eligió expandir el contrato y ahora ese método protegido es público. La pregunta realmente no debería ser si C++ lo permite, pero es correcto para su clase, contrato y futuros mantenedores. Claro que podría ser un mal olor, pero realmente necesita hacerlo bien para el caso de uso involucrado.

Si hace que el método protegido sea público, asegúrese de proporcionar adecuadamente la documentación interna para el responsable que explica la razón por la cual se toma esta decisión en particular.

En general, por razones de seguridad como se mencionó anteriormente, es probable que desee utilizar una función de delegado (con un nombre diferente) en la subclase. Entonces, en lugar de "get (int)", podrías tener "getAtIndex (int)" o algo así. Esto le permite refactorizar/proteger/abstraer/documentar más fácilmente eso en el futuro.