STI

5 views
Skip to first unread message

Nicolás Zuasti

unread,
Mar 21, 2012, 8:47:26 AM3/21/12
to rub...@googlegroups.com
Buenas, acabo de registrarme en el grupo. Sinceramente no tenia conciencia de su existir.

Hace un tiempo comence a programar en ruby y en RoR y la verdad fue algo asi como amor a primera vista. Principalmente vengo de Java y de Genexus (de lo que trabajo profecionalmente como instructor), y la verdad es que de momento Ruby es el unico lenguaje en el que me divierto trabajando, algo que concidero realmente importante.

Dejando las presentaciones de lado. Tengo una aplicacion donde por requeriemiento del cliente debo usar herencia para diagramar una jerarquia de clases que define la estructura de tipos de preguntas en formularios (texto, entero, decimal, booleano, etc). Investigue un poco y encontre que con STI puedo dejar todo en una tabla principal, llamemosle Tipos con un atributo especial (type) que guarda automagicamente el nombre de la clase representada por esa linea.

Basicamente en mi modelo no varia mucho el comportamiento de los objetos, ya que simplemente son validaciones especificas para cada tipo de dato definido.

La pregunta es STI es el mejor modelo a seguir? Entiendo que a nivel de performance es mejor tener todo en una gran tabla que usar X cantidad de joins para representar la jerarquia entera. Pero simplemente no me resulta tan intuitivo como deberia ser.

Gracias por leer y responder la consulta.

Saludos

Nicolás Berger

unread,
Mar 21, 2012, 8:57:42 AM3/21/12
to rub...@googlegroups.com
Hola Nicolás, bienvenido a la lista!

Yo creo que STI es una buena solución en este caso

Saludos!

2012/3/21 Nicolás Zuasti <nicoz...@gmail.com>:

Emilio Gutter

unread,
Mar 21, 2012, 9:02:26 AM3/21/12
to rub...@googlegroups.com
Hola Nicolas, 

Bienvenido al grupo!

2012/3/21 Nicolás Zuasti <nicoz...@gmail.com>

Buenas, acabo de registrarme en el grupo. Sinceramente no tenia conciencia de su existir.

Hace un tiempo comence a programar en ruby y en RoR y la verdad fue algo asi como amor a primera vista. Principalmente vengo de Java y de Genexus (de lo que trabajo profecionalmente como instructor), y la verdad es que de momento Ruby es el unico lenguaje en el que me divierto trabajando, algo que concidero realmente importante.

Dejando las presentaciones de lado. Tengo una aplicacion donde por requeriemiento del cliente debo usar herencia
El cliente te "requirio" usar herencia? En general los clientes piden funcionalidad y no suele ser buena idea mezclar en un requerimiento "que" es lo que el ciente necesita, con "como" resolver el problema :)
 
para diagramar una jerarquia de clases que define la estructura de tipos de preguntas en formularios (texto, entero, decimal, booleano, etc). Investigue un poco y encontre que con STI puedo dejar todo en una tabla principal, 
llamemosle Tipos con un atributo especial (type) que guarda automagicamente el nombre de la clase representada por esa linea.

Basicamente en mi modelo no varia mucho el comportamiento de los objetos, ya que simplemente son validaciones especificas para cada tipo de dato definido.
Me parece que lo podes resolver mejor sin herencia.. necesitas una sola Pregunta y diferentes Validadores .. solo tenes que colaborar con el validador correcto dependiendo el tipo de pregunta.. podes usar un Strategy pattern y posiblemente no haga falta escribir ningún "if" para resolver el problema :)

La pregunta es STI es el mejor modelo a seguir? Entiendo que a nivel de performance es mejor tener todo en una gran tabla que usar X cantidad de joins para representar la jerarquia entera. Pero simplemente no me resulta tan intuitivo como deberia ser.
Trato de evitar la herencia en general y especialmente el STI.. pero más por una cuestión de diseño que por un tema de performance. 

Saludos,
Emilio

Nicolas Zuasti

unread,
Mar 21, 2012, 9:12:53 AM3/21/12
to rub...@googlegroups.com
Mi cliente es el desarrollador del sistema original (construido en java) y solicita que mantenga el esquema de clases. Trate de explicarle que hay mejores (o diferentes) alternativas, pero no da el brazo a torcer.

Voy a intentar presentarle ambas soluciones y ver que pasa. Es mas facil cuando el cliente sabe lo que quiere obtener, y no esta particularmente interesado en el como se lo estructuras :P

A.P. Nicolás Zuasti
@zonical.net/cv


2012/3/21 Emilio Gutter <egu...@gmail.com>
Reply all
Reply to author
Forward
0 new messages