Poniendo nombres a objetos GeneXus


Una de las cosas mas importantes (y difíciles) en Ingeniería de Software es ponerle buenos nombres a todas las cosas que usamos. 

Un buen nombre ayuda a entender que es lo que un programa hace, y por lo tanto, hace mas rapido los cambios que se necesiten y por lo tanto se puede ser mas productivo. 

Una técnica sencilla, que me ayuda a elegir buenos nombres de parámetros y de objetos, es la de solo ver la regla parm()

Ej:
Parm(IN:&DocumentID, OUT:&DocumentName) ;

Esto parece ser un objeto que dado un ID de documento, devuelve el Nombre del mismo. 

Una vez que vemos que es lo que el proceso debe hacer por los parámetros, ponerle un buen nombre es mucho mas faci. 

En los casos que las variables tienen nombres mal puesto, es mucho mas dificil deducir que es lo que hace el objeto solo con la regla parm(). Por eso, conviene renombrar los parámetros hasta que tengan un significado con solo verlo. 

Ej2:

Parm(IN:&Pais, OUT:&Permite);

El parámetro &Permite es Boolean, pero no es facil deducir de los parámetros que es lo que hace el objeto.

Si renombramos la variable y ponemos

Parm(IN:&PaisID, OUT:&PermiteCertificadoOrigenDigital);

queda un poco mas claro cual es el propósito del objeto y podria llamarse PaisPermiteCertificadoOrigenDigital()

Luego sería usado asi:

if PaisPermiteCertificadoOrigenDigital(&PaisID) 
...
endif

que queda bastante claro su uso y se entiende bastante bien. 

Cosas a tener en cuenta:

1) Demasiados parámetros. 
Cuando se tienen demasiados parámetros es una mala señal. Hay que evaluar si no se puede pasar un SDT como parámetro que agrupe varios de los parámetros para que quede el código mas claro. 

2) Parámetros de Salida. 
Conviene que los objetos tengan un único parámetros de salida, para que quede claro que es lo que recupera dicho objeto. 

3) Separar los objetos en QUERYS y COMMANDS. 
Los QUERYS recuperan algo y lo devuelven sin modificar la base de datos ni el estado. 
Los COMMANDS son los que hacen los cambios de estado y la base de datos, pero no devuelven nada. Estos objetos deben manejar los errores y registrarlos en otro lado para que puedan ser procesados a posterior. 

Con estas sencillas técnicas, mejora bastante la forma en que podemos nombrar objetos y por lo tanto mejora también el entender y mantener las aplicacion de forma mas eficiente. 

Comentarios

  1. Para mi, los parámetros, a parte de tus recomendaciones deberían distribuirse de otra forma, sobre todo cuando son muchos, por ejemplo:
    parm(
    in: par1,
    in: par2,
    out: salida1,
    out: salida2
    );

    ResponderBorrar
    Respuestas
    1. Intento en todos mi programas cumplir con:
      1) No mas de 6 parámetros.
      2) Solo 1 parámetro de salida.
      3) Usar parámetros INOUT solo en casos muy justificados.

      Los objetos que cumplen con esas reglas, son mucho mas fáciles de entender y de manipular.
      Si hay que pasar muchos parámetros, es una mala señal, posiblemente se necesite tener una estructura auxiliar (SDT) que agrupe parámetros parecidos. También puede ser una señal de algo para mejorar en el modelo de datos.

      Borrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

Aplicación monolítica o distribuida?

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.