Hola amigos.
Estoy desarollando una pequeña aplicación en Delphi. Por su puesto, he intentado enforcarlo desde el punto de vista OOP, y claro, tengo un montón de clases, y derivadas.
La aplicación es fundamentalmente matemática: leo ficheros con datos (coordenadas), y ficheros de configuración, y dependiendo del fichero de configuración manipulo las coordenadas de una forma u otra.
Ahora me he dando cuenta de que tengo que crear un especie de protocolo, o log, para que aunque no esté en modo debug, sepa lo que pasa internamente en el programa, o el usuario sepa lo que pasa: que pasos se han dado, cuales han sido los resultados intermedios, cuanto tiempo ha costado calcularlo, ... Asín que me hace falta un fichero log. Para ello crearé la clase LOG y luego un único objeto LOG, y ahí va mi pregunta:
Que considerais mejor,
1. crear un objeto log, que sea global a todo, y a lo que todos los objetos tengan acceso, o
2. crear el objeto log, y pasarselo a todos los objetos (que puede resultar algo engorioso y repetitivo).
¿Hay otras opciones?
De momento me vale con una aplicación en línea de comandos. Luego le habrá que crear una interfaz gráfica, pero el fichero log deberá permanecer, y preferiblemente como fichero texto.
fichero log
Comenzado por
zampa
, dic 03 2011 05:36
3 respuestas en este tema
#2
Delphius
-
- Administrador
-
- 6.301 mensajes
Advanced Member
- LocationArgentina
Escrito 04 diciembre 2011 - 12:59
Hola zampa,
Habría que considerar los efectos de acoplamiento de esta clase con las otras; como así también sore la cohesión.
No es que exista una única respuesta a tu pregunta. Más bien... se trata de pros y contras según cada caso.
No se puede (o mejor dicho, no debería) generalizar y asumir que una respuesta será la perfecta y certera siempre.
Naturalmente para poder asesorarte se necesita de una mayor explicación de cómo está estructuradas tus clases, sin ello estaremos en ese mar de subjetividad.
En principio, y por lo general, el registro de un .log tiene lugar en una única clase. Un punto global. Por lo que tu clase Log debe actuar como singleton. Luego, cada objeto le envía a ésta el mensaje adecuado para llevar registro.
Visto desde la pura semántica y conceptos de OO, diríamos que se establece un contrato entre la clase Log y las clases clientes. La clase Log ofrece una interfaz (la parte abierta, visible al exterior) que los clientes deben respetar. De ser necesario cada cliente deberá asumir la responsabilidad de hacer el tratamiento adecuado de los datos que necesite la clase log según como se defina el contrato.
Esto es congruente con el pto 1 que señalas. El objeto es global, y los interesados se comunican con éste.
El enfoque del punto 2 no es deseable porque en última se está formando un acoplamiento innecesario; alterando la propia cohesión de la clase y ni que decir.... peligroso. De ser un único objeto, si éste se pasa a las clases clientes con el fin de que se cree o forme un vínculo ya sea de atributo o por parámetro existe el potencial de eliminarlo y de este modo nuevas referencias a este objeto por otra clase dará errores de Access Violation.
Este no es en si un peligro, ya que si uno se asegura de tener un buen código y de no hacer .Free y/o liberar las asociaciones no hay inconveniente de que exista esta visibilidad de atributo o por parámetro (que dicho sea de paso, son las dos visibilidades de mayor conveniencia).
El peligro está más que nada en que ahora la lógica está difusa y repartida entre la clase log y cada clase cliente.... se han mezclado responsabilidades y funcionalidades... y como señalas, puede dar origen a código repetido en cada clase cliente.
Pero en ocasiones este enfoque (pto 1) no es adecuado, y es conveniente delegar en cada clase que tenga interés de llevar una bitácora esta responsabilidad. Este enfoque podría ser útil si el dominio ya cuenta con muchísimas clases, y cada una está muy especializada y tiene sus particularidades para, y sobre qué, almacenar en un log. De este modo existirán tantos archivos log como clases se necesiten. Naturalmente esto provoca una disminución de la cohesión... ahora las clases incorporan, además de sus propias responsabilidades, el manejo de archivos .log.
Existen naturalmente otras maneras de encarar el problema. Una posible alternativa (que tiene tanto de bueno como de malo) es disponer de una clase Proxy (leer sobre el patrón Proxy) por cada potencial clase que genere logs. Entonces las clases clientes actúan sobre el Proxy como si se tratase de una clase X común, el Proxy X simplemente delega en el objeto real la responsabilidad extra de generar los archivos log y el resto de las cosas van por un objeto real común.
Esa es una de las tantas variaciones de Proxy. Se lo conoce como Proxy Virtual: dentro del Proxy se esconden los objetos reales; para el caso uno que hace el trabajo común y corriente, y otro que se encargue de llevar el log.
En el mundo de la POO no existe una única respuesta para todo. En la medida que vayas experimentando te encontrarás con estos tipos de preguntas. Lo importante es que vayas descubriendo las posibilidades de diseño que mejor te equilibren acoplamiento y cohesión. Si aún no entraste en tema, sugiero una lectura sobre patrones de diseño... comienza por los patrones GRASP que son la piedra angular.
Los patrones tampoco te darán la respuesta mágica pero te ayudarán a reordenarte las ideas y te abre la cabeza hacia un mundo de perspectivas que va más allá de la mirada clásica y básica del paradigma OO.
Espero haberte servido de ayuda en algo.
Saludos,
Habría que considerar los efectos de acoplamiento de esta clase con las otras; como así también sore la cohesión.
No es que exista una única respuesta a tu pregunta. Más bien... se trata de pros y contras según cada caso.
No se puede (o mejor dicho, no debería) generalizar y asumir que una respuesta será la perfecta y certera siempre.
Naturalmente para poder asesorarte se necesita de una mayor explicación de cómo está estructuradas tus clases, sin ello estaremos en ese mar de subjetividad.
En principio, y por lo general, el registro de un .log tiene lugar en una única clase. Un punto global. Por lo que tu clase Log debe actuar como singleton. Luego, cada objeto le envía a ésta el mensaje adecuado para llevar registro.
Visto desde la pura semántica y conceptos de OO, diríamos que se establece un contrato entre la clase Log y las clases clientes. La clase Log ofrece una interfaz (la parte abierta, visible al exterior) que los clientes deben respetar. De ser necesario cada cliente deberá asumir la responsabilidad de hacer el tratamiento adecuado de los datos que necesite la clase log según como se defina el contrato.
Esto es congruente con el pto 1 que señalas. El objeto es global, y los interesados se comunican con éste.
El enfoque del punto 2 no es deseable porque en última se está formando un acoplamiento innecesario; alterando la propia cohesión de la clase y ni que decir.... peligroso. De ser un único objeto, si éste se pasa a las clases clientes con el fin de que se cree o forme un vínculo ya sea de atributo o por parámetro existe el potencial de eliminarlo y de este modo nuevas referencias a este objeto por otra clase dará errores de Access Violation.
Este no es en si un peligro, ya que si uno se asegura de tener un buen código y de no hacer .Free y/o liberar las asociaciones no hay inconveniente de que exista esta visibilidad de atributo o por parámetro (que dicho sea de paso, son las dos visibilidades de mayor conveniencia).
El peligro está más que nada en que ahora la lógica está difusa y repartida entre la clase log y cada clase cliente.... se han mezclado responsabilidades y funcionalidades... y como señalas, puede dar origen a código repetido en cada clase cliente.
Pero en ocasiones este enfoque (pto 1) no es adecuado, y es conveniente delegar en cada clase que tenga interés de llevar una bitácora esta responsabilidad. Este enfoque podría ser útil si el dominio ya cuenta con muchísimas clases, y cada una está muy especializada y tiene sus particularidades para, y sobre qué, almacenar en un log. De este modo existirán tantos archivos log como clases se necesiten. Naturalmente esto provoca una disminución de la cohesión... ahora las clases incorporan, además de sus propias responsabilidades, el manejo de archivos .log.
Existen naturalmente otras maneras de encarar el problema. Una posible alternativa (que tiene tanto de bueno como de malo) es disponer de una clase Proxy (leer sobre el patrón Proxy) por cada potencial clase que genere logs. Entonces las clases clientes actúan sobre el Proxy como si se tratase de una clase X común, el Proxy X simplemente delega en el objeto real la responsabilidad extra de generar los archivos log y el resto de las cosas van por un objeto real común.
Esa es una de las tantas variaciones de Proxy. Se lo conoce como Proxy Virtual: dentro del Proxy se esconden los objetos reales; para el caso uno que hace el trabajo común y corriente, y otro que se encargue de llevar el log.
En el mundo de la POO no existe una única respuesta para todo. En la medida que vayas experimentando te encontrarás con estos tipos de preguntas. Lo importante es que vayas descubriendo las posibilidades de diseño que mejor te equilibren acoplamiento y cohesión. Si aún no entraste en tema, sugiero una lectura sobre patrones de diseño... comienza por los patrones GRASP que son la piedra angular.
Los patrones tampoco te darán la respuesta mágica pero te ayudarán a reordenarte las ideas y te abre la cabeza hacia un mundo de perspectivas que va más allá de la mirada clásica y básica del paradigma OO.
Espero haberte servido de ayuda en algo.
Saludos,
#3
cadetill
-
- Moderadores
-
- 994 mensajes
Advanced Member
- LocationEspaña
Escrito 05 diciembre 2011 - 08:47
Buenas,
Cuando necesito realizar un log de operaciones uso una clase a la que llamo mediante funciones de clase. De esta manera me ahorro de pasar objetos por parámetro, el tener un objeto creado con acceso por todos lados o el tener que estar picando el código de creación y destrucción del objeto log. Así que sí, existe otra opción y seguro que existirán más
Nos leemos
.............
¿Hay otras opciones?
.............
Cuando necesito realizar un log de operaciones uso una clase a la que llamo mediante funciones de clase. De esta manera me ahorro de pasar objetos por parámetro, el tener un objeto creado con acceso por todos lados o el tener que estar picando el código de creación y destrucción del objeto log. Así que sí, existe otra opción y seguro que existirán más
Nos leemos
#4
Vivas84
-
- Miembros
-
- 23 mensajes
Member
Escrito 10 febrero 2012 - 05:00
Yo por sencillez y claridad en el código usaría una variable global.
Te propondría probar en una interfaz gráfica con un Form con un TMemo, y que dicha clase tuviese una única función pública, que se encargase de insertar un comentario, y comprobar si se ha llegado a un número X de comentarios, y cuando se llegue a ese número, lo salve en un fichero y limpie el memo, de forma que pudieses tener una determinada carpeta con la información de los memos.
Bastante simple y útil para lo que se quiere, pero me surje una duda como veo que comentas lo del tiempo de ejecución, ¿habría algún tipo de diferencia en cuestión de consumo de memoria/tiempo entre uno y otro caso?
Te propondría probar en una interfaz gráfica con un Form con un TMemo, y que dicha clase tuviese una única función pública, que se encargase de insertar un comentario, y comprobar si se ha llegado a un número X de comentarios, y cuando se llegue a ese número, lo salve en un fichero y limpie el memo, de forma que pudieses tener una determinada carpeta con la información de los memos.
Bastante simple y útil para lo que se quiere, pero me surje una duda como veo que comentas lo del tiempo de ejecución, ¿habría algún tipo de diferencia en cuestión de consumo de memoria/tiempo entre uno y otro caso?
