A continuación un extracto de "Cómo programar con Gambas" que plantea encontrar problemas potenciales en un bosquejo de una clase que se está diseñando. ¿Puedes encontrarlos?

Analiza este código para verificar la presencia de deficiencias conceptuales, para anticipar problemas futuros y, entonces, pensar en qué cambios le harías.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Ya sabes que yo no soy ningún experto en POO, pero así de entrada sólo veo como posible fuente de problemas el que dispongas de una propiedad Message, cuyo nombre colisiona con la función del sistema.
Supongo que un manejo cuidadoso de los ambitos de visibilidad y demás evitaría los problemas, y también imagino que todos esos problemas te surgirían en tiempo de diseño y no de ejecución... pero aún así yo cambiaría eso de Message por Body, Content o algo así...

===================
No podemos regresar

En principio no entiendo la necesidad de declarar las propiedades como STATIC y segundo, los métodos de propiedades deben de ser PUBLICOS.

Falta implementar los valores de lectura/escritura de todos los métodos de propiedades y de la propia función Send(), aunque es obvio porque como dices, es sólo un bosquejo.

Como la función sólo emplea las propiedades para escribir valores, no veo necesario implementar los métodos _Read() de las propiedades. (No existe un modificador para las propiedades de sólo escritura, como en el caso de las de sólo lectura: PROPERTY READ, PROPERTY WRITE)

Por último, sólo se puede declarar un argumento opcional al final de la lista de argumentos (en el procedimiento Send()).

Eso es lo que veo... puede que me haya perdido algo  

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Shordi:

Citar:

... así de entrada sólo veo como posible fuente de problemas el que dispongas de una propiedad Message, cuyo nombre colisiona con la función del sistema.

Luego me tomaré el tiempo para explicar las reglas de ámbito, pero básicamente

es algo diferente de

Entonces gambas puede fácilmente diferenciarlas y no hay conflictos. Benoit trabajó cuidadosamente estos aspectos.

Jesús. Yo sé que sabes las respuestas, pero gracias de todos modos por darme pie a explicar estas cosas que a cualquiera podrían surgirle como dudas.

Citar:

En principio no entiendo la necesidad de declarar las propiedades como STATIC

Es necesario, porque la clase debe ser estática y para que así sea todos sus métodos, atributos y propiedades deben ser STATIC. La clase debe ser estática porque no tiene sentido crear objetos a partir de ella, sería algo totalmente innecesario. En "Cómo crear componentes en gambas" se explica con más detalle.

Citar:

los métodos de propiedades deben de ser PUBLICOS

Este es el típico tipo de cuestión que manejamos todos los días en forma práctica que pero si nos lo preguntan en forma teórica fácilmente podemos equivocarnos (es la diferencia entre conocimiento o habilidad práctica y conocimiento teórico o conceptual).

En gambas las propiedades no llevan modificador de ámbito (PUBLIC | PRIVATE) porque siempre son públicas. Los métodos _WRITE y _READ de las propiedades son parte de la implementación y por ello deben ser privados (PRIVATE).

Citar:

Como la función sólo emplea las propiedades para escribir valores, no veo necesario implementar los métodos _Read() de las propiedades. (No existe un modificador para las propiedades de sólo escritura, como en el caso de las de sólo lectura: PROPERTY READ, PROPERTY WRITE)

Exacto, hay una sobrecarga debido a que las propiedades siempre deben tener su implementación del método _READ, pero entonces la pregunta que queda pendiente es ¿cómo evitar esa sobrecarga?

Citar:

Por último, sólo se puede declarar un argumento opcional al final de la lista de argumentos (en el procedimiento Send()

Y eso se cumple, ya que todos los argumentos son opcionales. Para que quede claro, cuando en la lista de argumentos aparece uno que es opcional, todos los que vienen después también son opcionales (aunque no se especifique la palabra clave OPTIONAL para cada uno). Pero antes del primer argumento opcional puede haber argumentos obligatorios, pero también puede no haberlos.

Citar:

Eso es lo que veo... puede que me haya perdido algo

Bueno, creo que sí. En el cómo "Cómo programar componentes" especialmente en las partes 3 y 4 está la justificación para el diseño que propongo, pero las preguntas que planteo y la invitación a analizar probables problemas a futuro, deberían desnudar ciertas falencias en el diseño: la primera está relacionada con lo que mencionaste sobre las propiedades, pero no está resuelta; la segunda está relacionada con ... bueno ese problema aún nadie lo ha mencionado así que esperemos a ver quién se da cuenta antes.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Me sobrepasáis... qué bonito es eso de tener siempre cosas nuevas que aprender.

===================
No podemos regresar

jguardon escribió: [Ver mensaje]

Por último, sólo se puede declarar un argumento opcional al final de la lista de argumentos (en el procedimiento Send()).

Sí, eso está claro, pero ¿qué sentido tiene llamar a esa función sin argumentos?. Además, creo recordar que al ser opcionales desde el primero, eso te obliga a declarar todos o ninguno ¿? Tengo dudas aún.

Bueno, pues no acerté ni una... me rindo! Aparte de que, ya puestos a divagar, si la función (o rutina, ya que no devuelve valores) está pensada para aceptar todos los argumentos necesarios, ¿para qué queremos las propiedades?

Buff, me voy a quedar más calvo de lo que estoy. Entre gambas y Python + Qt  ya se me va la olla!

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Citar:

¿qué sentido tiene llamar a esa función sin argumentos?.

Los argumentos son opcionales el diseño inicial plantea que debe ser posible ejecutar el método Send sin argumentos y en ese caso se utilizarían las propiedades para obtener los valores que se pasarían al comando Notify-Send. Pero esto no quiere decir que el diseño inicial sea el mejor.

Citar:

Además, creo recordar que al ser opcionales desde el primero, eso te obliga a declarar todos o ninguno ¿? Tengo dudas aún.

Si son opcionales puedes establecer cualquier subconjunto de los argumentos (ninguno, algunos o todos).

Citar:

Bueno, pues no acerté ni una

¿Cómo que no?  En tu mensaje anterior ya cuestionaste esto:

Citar:

Como la función sólo emplea las propiedades para escribir valores, no veo necesario implementar los métodos _Read() de las propiedades. (No existe un modificador para las propiedades de sólo escritura, como en el caso de las de sólo lectura: PROPERTY READ, PROPERTY WRITE)

Citar:

Aparte de que, ya puestos a divagar, si la función (o rutina, ya que no devuelve valores) está pensada para aceptar todos los argumentos necesarios, ¿para qué queremos las propiedades?

Es un cuestionamiento válido. La clase Notify no es común porque es un envoltorio para un comando externo. Cuando se se escriben este tipo de clases se intenta simplificar la interfaz original, flexibilizarla o adecuarla al estilo del lenguaje que la incorpora. De allí que el planteo inicial sea tener dos interfaces para establecer los argumentos del comando Notify-Send: a-. Por medio de propiedades. b-. Como argumentos del método Send.

Entonces, es otro acierto tuyo porque en realidad la duplicación de interfaces no ayuda mucho a una utilización más sencilla, sólo brinda un medio alternativo para pasar los valores produciendo una sobrecarga en la codificación de la clase. Entonces o se elimina la interfaz que obliga a escribir más código o se encuentra una manera de eliminar aunque sea parte de esa sobrecarga.

Lo anterior conduce a la consideración más general de que la POO casi siempre produce un sobre-trabajo cuando lo que se realiza es más bien pequeño, aunque generalmente también introduce una mayor flexibilidad y claridad conceptual.

El otro problema tiene que ver con el ocultamiento de la implementación.

===================
Cómo programar con Gambas

Speed Books: informática libre.