Largas cadenas de delegación en C++

En mi experiencia, cadenas como esa a menudo contienen captadores que son menos que triviales, lo que conduce a ineficiencias. Creo que (1) es un enfoque razonable. El uso de objetos proxy parece una exageración. Preferiría ver un bloqueo en un puntero NULO en lugar de usar objetos proxy.

Esta larga cadena de delegación no debería suceder si se sigue la Ley de Deméter. A menudo he argumentado con algunos de sus defensores que se aferran a ella demasiado concienzudamente, pero si llegas al punto de preguntarte cómo manejar mejor las largas cadenas de delegación, probablemente deberías ser un poco más obediente con sus recomendaciones.

Pregunta interesante, creo que esto está abierto a la interpretación, pero:

Mis Dos Centavos

Los patrones de diseño son solo soluciones reutilizables a problemas comunes que son lo suficientemente genéricos como para ser aplicados ampliamente en la programación orientada a objetos (generalmente). Muchos patrones comunes lo iniciarán con interfaces, cadenas de herencia y/o relaciones de contención que resultarán en que use el encadenamiento para llamar a las cosas hasta cierto punto. Los patrones no están tratando de resolver un problema de programación como este, sin embargo, el encadenamiento es solo un efecto secundario de ellos resolviendo los problemas funcionales a mano. Así que, realmente no lo consideraría un patrón.

Igualmente, los anti-patrones son enfoques que (en mi mente) contrarrestan el propósito de los patrones de diseño. Por ejemplo, los patrones de diseño tienen que ver con la estructura y la adaptabilidad de su código. La gente considera un singleton un anti-patrón, ya que (a menudo, no siempre) resulta en la tela de araña como el código debido al hecho de que inherentemente crea un global, y cuando tienes muchos, tu diseño se deteriora rápidamente.

Así que, nuevamente, su problema de encadenamiento no necesariamente indica un diseño bueno o malo, no está relacionado con los objetivos funcionales de los patrones o los inconvenientes de los anti - patrones. Algunos diseños solo tienen muchos objetos anidados, incluso cuando están bien diseñados.

¿Qué hacer al respecto:

Las largas cadenas de delegación definitivamente pueden ser un dolor en el trasero después de un tiempo, y siempre y cuando su el diseño dicta que los punteros en esas cadenas no se reasignarán, creo que guardar un puntero temporal al punto de la cadena que le interesa está completamente bien (ámbito de función o menos preferiblemente).

Personalmente, sin embargo, estoy en contra de guardar un puntero permanente a una parte de la cadena como miembro de la clase, ya que he visto que terminan en personas que tienen 30 punteros a sub objetos almacenados permanentemente, y se pierde toda concepción de cómo se presentan los objetos en el patrón o arquitectura con la que estás trabajando.

Otro pensamiento - No estoy seguro de si me gusta esto o no, pero he visto a algunas personas crear una función privada (para su cordura) que navega por la cadena para que pueda recordar eso y no tratar con problemas sobre si su puntero cambia o no bajo las cubiertas, o si tiene o no nulos. Puede ser bueno envolver toda esa lógica una vez, poner un buen comentario en la parte superior de la función indicando de qué parte de la cadena obtiene el puntero, y luego simplemente use la función resultado directamente en su código en lugar de usar su cadena de delegación cada vez.

Rendimiento

Mi última nota sería que este enfoque de wrap-in-function, así como su enfoque de cadena de delegación, sufren inconvenientes de rendimiento. Guardar un puntero temporal le permite evitar las dos desreferencias adicionales potencialmente muchas veces si está utilizando estos objetos en un bucle. Igualmente, almacenar el puntero de la llamada a la función evitará la sobrecarga de una función extra llamar a cada ciclo de bucle.

Para bool Exists = Env->FileSystem->FileExists( "foo.txt" ); Prefiero un desglose aún más detallado de su cadena, por lo que en mi mundo ideal, hay las siguientes líneas de código:

Environment* env = GetEnv();
FileSystem* fs = env->FileSystem;
bool exists = fs->FileExists( "foo.txt" );

Y por qué? Algunas razones:

1. legibilidad : mi atención se pierde hasta que tengo que leer hasta el final de la línea en el caso de bool Exists = Env->FileSystem->FileExists( "foo.txt" ); Es demasiado largo para mí.
2. validez : las consideraciones que usted mencionó los objetos son, si su empresa mañana contrata a un nuevo programador y comienza a escribir código, el día después de mañana los objetos podrían no estar allí. Estas largas colas son bastante antipáticas, las personas nuevas pueden asustarse de ellas y harán algo interesante, como optimizarlas... que tomará más tiempo adicional programador experimentado para arreglar.
3. depuración: si por casualidad (y después de haber contratado al nuevo programador) la aplicación lanza un fallo de segmentación en la larga lista de cadena es bastante difícil averiguar qué objeto era el culpable. El más detallado el desglose más fácil de encontrar la ubicación del error.
4. speed: si necesita hacer muchas llamadas para obtener los mismos elementos de la cadena, podría ser más rápido "extraer" una variable local de la cadena en lugar de llamar a una función getter "adecuada" para ella. No se si su código es de producción o no, pero parece perder la función getter "apropiada", en su lugar parece usar solo el atributo.

Las largas cadenas de delegación son un poco un olor a diseño para mí.

Lo que me dice una cadena de delegación es que una pieza de código tiene acceso profundo a una pieza de código no relacionada, lo que me hace pensar en acoplamiento alto, que va en contra de los principios de diseño SÓLIDOS.

El principal problema que tengo con esto es la mantenibilidad. Si usted está alcanzando dos niveles de profundidad, que son dos piezas independientes de código que podrían evolucionar por su cuenta y romper debajo de usted. Así de rápido compuestos cuando tiene funciones dentro de la cadena, porque pueden contener cadenas propias - por ejemplo, Renderer->GetCanvas() podría estar eligiendo el lienzo basado en información de otra jerarquía de objetos y es difícil imponer una ruta de código que no termina llegando profundamente a los objetos durante la vida útil del código base.

La mejor manera sería crear una arquitectura que obedeciera los principios SÓLIDOS y utilizara técnicas como Inyección de dependencias y Inversión de Control para garantizar que sus objetos siempre tengan acceso a lo que necesitan para realizar sus tareas. Este enfoque también se presta bien a las pruebas automatizadas y unitarias.

Solo mis 2 centavos.

Si es posible, usaría referencias en lugar de punteros. Por lo tanto, los delegados tienen la garantía de devolver objetos válidos o lanzar excepción.

clCanvas & C = Env.Renderer().GetCanvas();

Para objetos que no pueden existir proporcionaré métodos adicionales como has, is, etc.

if ( Env.HasRenderer() ) clCanvas* C = Env.Renderer().GetCanvas();

Si puedes garantizar que todos los objetos existen, realmente no veo un problema en lo que estás haciendo. Como otros han mencionado, incluso si piensas que NULL nunca sucederá, puede suceder de todos modos.

Dicho esto, veo que usas punteros desnudos en todas partes. Lo que sugeriría es que empieces a usar punteros inteligentes en su lugar. Cuando se utiliza el operador ->, un puntero inteligente generalmente lanzará si el puntero es NULO. Así que evitas un SegFault. No solo eso, si utilizas smart punteros, puedes guardar copias y los objetos no desaparecen bajo tus pies. Debe restablecer explícitamente cada puntero inteligente antes de que el puntero pase a NULL.

Dicho esto, no evitaría que el operador -> lanzara de vez en cuando.

De lo contrario, prefiero utilizar el enfoque propuesto por AProgrammer. Si el objeto A necesita un puntero al objeto C apuntado por el objeto B, entonces el trabajo que el objeto A está haciendo es probablemente algo que el objeto B debería estar haciendo. Así que A puede garantizar que tiene un puntero a B en todo momento (porque tiene un puntero compartido a B y por lo tanto no puede ir a NULL) y por lo tanto siempre puede llamar a una función en B para hacer la acción Z en el objeto C. En la función Z, B sabe si siempre tiene un puntero a C o no. Eso es parte de la implementación de su B.

Tenga en cuenta que con C++11 tiene std::smart_ptr, ¡así que úselo!