c++ - sierra - ¿Es este patrón de protección de acceso orientado a las teclas un idioma conocido?
configurar teclado latinoamericano en mac (4)
Matthieu M. sacó a relucir un patrón de protección de acceso en esta respuesta que había visto antes, pero que nunca consideró intencionalmente un patrón:
class SomeKey {
friend class Foo;
SomeKey() {}
// possibly make it non-copyable too
};
class Bar {
public:
void protectedMethod(SomeKey);
};
Aquí solo un friend
de la clase clave tiene acceso a protectedMethod()
:
class Foo {
void do_stuff(Bar& b) {
b.protectedMethod(SomeKey()); // fine, Foo is friend of SomeKey
}
};
class Baz {
void do_stuff(Bar& b) {
b.protectedMethod(SomeKey()); // error, SomeKey::SomeKey() is private
}
};
Permite un control de acceso más fino y granular que hacer que Foo
friend
de Bar
y evita patrones de proxying más complicados.
¿Alguien sabe si este enfoque ya tiene un nombre, es decir, es un patrón conocido?
Está muy cerca de esto:
http://minorfs.wordpress.com/2013/01/18/raiicap-pattern-injected-singleton-alternative-for-c/
Básicamente, si considera que una referencia a un objeto de clase bien diseñada debe proporcionar el control de acceso que necesita para implementar cualquier política de control de acceso que realmente tenga sentido, aplicar este patrón a cualquier otra cosa que no sea el constructor no parece tener mucho sentido.
Como dice el artículo, si utiliza esta clave junto con los constructores para lo que el control de acceso puede tener sentido, los objetos que representan partes significativas de los recursos de susto, que en C ++ generalmente se implementarían como objetos RAII, que el nombre RAIICap o RAII -Capacidad tendría sentido.
http://www.eros-os.org/essays/capintro.html
Alternativamente, puede referirse a él con un nombre más general como autoridad de construcción.
La implementación en el artículo está un poco centrada en el principal, es decir, las principales necesidades para crear todas las claves de autoridad. Puede ampliarlo y hacerlo más flexible agregando un constructor público adicional para la clave en sí:
template <typename T>
class construct_authority {
public:
construct_authority(construct_authority<void> const&)
friend int main(int,char **);
private:
construct_authority(){}
};
De esta forma, main podría delegar la creación de claves a otras partes del programa.
Personalmente, creo que el nombre RAIICap es bastante apropiado para la parte útil de este patrón.
Hace un tiempo, propuse que esta simple plantilla anterior se pudiera agregar a la biblioteca estándar.
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/p_v-aYIvO1E
Lamentablemente, hay problemas con la idea de que puede haber una huella digital principal que constituye una raíz computacional, por lo que algo así no puede tener un lugar en la biblioteca estándar. Habiendo dicho esto, al menos para el uso con el constructor de clases RAII, este patrón parece ser bastante útil.
Gracias a su otra pregunta , parece que este patrón se conoce ahora como el patrón "clave".
En C ++ 11, se vuelve aún más limpio, porque en lugar de llamar
b.protectedMethod(SomeKey());
solo puede llamar:
b.protectedMethod({});
un hombre aburrido como yo haría el código más profundo:
int FraudKey=0;
b.protectedMethod(reinterpret_cast<SomeKey&>(FraudKey));