Obligatoreidad de algunos conceptos

Obligatoreidad de algunos conceptos

de Jerónimo Ismael Acosta Monteavaro -
Número de respuestas: 8

Buenas. Quisiera consultar si son o no ciertas las siguientes restricciones:

1. Se debe utilizar el patrón singeton. Más específicamente, los controladores necesariamente deben ser  singleton; no pueden implementarse alternativas.

2.1. Todo caso de uso debe invocar (de forma directa) métodos de un único controlador; no puede utilizar varios, o invocar a otro caso de uso.

2.2. La consola debe utilizar de forma directa los controladores que manipulan (también de forma directa) los datos; no pueden haber "varias capas" entre la consola y los datos.

Gracias.

En respuesta a Jerónimo Ismael Acosta Monteavaro

Re: Obligatoreidad de algunos conceptos

de Antonio Mauttone -
Hola, respecto a la pregunta 1, los controladores deben ser singleton si además tienen la responsabilidad de almacenar colecciones de instancias.

Por otra parte, 2.1 y 2.2 son correctos.

Saludos
En respuesta a Antonio Mauttone

Re: Obligatoreidad de algunos conceptos

de Jerónimo Ismael Acosta Monteavaro -

Gracias por la respuesta profe. Me genera la siguiente duda: 

* Los controladores en conjunto proveen métodos públicos para modificar cada dato del sistema (relevantes al negocio: usuarios, compras, etc).
* Implementar el patrón singleton implica un método estático del estilo GetInstance.
* Si no se toma ninguna medida extra que restrinja el acceso al namespace de la clase, entonces el controlador es en escencia global, y cualquier objeto (de cualquier tipo, y en cualquier parte del programa) adquiere la capacidad de accederlo mediante su GetInstance, y usar sus métodos para modificar los datos del negocio. 

Quisiera saber si mi razonamiento tiene algún error conceptual, porque esto me suena muy problemático.

Saludos.

En respuesta a Antonio Mauttone

Re: Obligatoreidad de algunos conceptos

de Gennaro Vincenzo Monetti Cracco -
No me queda claro por qué 2.1 es correcto. Entiendo que un caso de uso no pueda "invocar" a otro, pero por qué un mismo caso de uso no puede usar más de un controlador? Si bien me parece que tiene sentido que se prefiera usar un único controlador por caso de uso, esa restricción nos obliga a tener operaciones que lo único que hacen es invocar una operación de otro controlador y retornar el resultado.
En respuesta a Gennaro Vincenzo Monetti Cracco

Re: Obligatoreidad de algunos conceptos

de Antonio Mauttone -
Hola, se admiten variantes, que están sujetas a coordinación con sus respectivos docentes de monitoreo.

Saludos
En respuesta a Antonio Mauttone

Re: Obligatoreidad de algunos conceptos

de Jerónimo Ismael Acosta Monteavaro -
Yo no sé por qué tiene sentido que un caso de uso no pueda invocar a otro. Si en múltiples casos de uso necesito hacer cosas como listar y seleccionar usuarios o productos, estoy repitiendo muchísimo código. Ya existe un caso de uso que lista usuarios, ¿por qué no puedo ejecutar su código desde otro caso de uso, para así listar usuarios allí, en lugar de esencialmente copy-pastear todo el contenido?.

Respecto a los controladores que llaman a otros, es cierto, en mi grupo está pasando lo mismo. Tenemos un mismo método repetido en diversos controladores: todos menos uno funcionan como middleman, que invocan a ese uno y retornan sin hacer más. No me queda claro qué ventaja aporta: te permite desacoplar el caso de uso de ese método, al precio de crear un método en otro controlador, y acoplar eso en su lugar (además, la consola ya estaba acoplada al resto de controladores de todos modos, mediante lo demás casos de uso). También creo que ensucia mucho las interfaces: parece incorrecto tener algo como ControladorComentario::ListarUsuarios (si controla comentarios, ¿por qué lista usuarios?).

Planteo estas dudas aquí porque son de índole general. Prefiero no utilizar tiempo del monitoreo con esto, ya que es escaso.

Saludos.
En respuesta a Jerónimo Ismael Acosta Monteavaro

Re: Obligatoreidad de algunos conceptos

de Antonio Mauttone -
Hola, el tema tiene varias puntas y por lo tanto es difícil de discutir por este medio. Por otra parte, no es un tema central en este curso, sino que necesitamos abordarlo en el laboratorio dado que se maneja interacción entre capas de presentación y lógica.
Hay diferentes opciones, cada una con ventajas y desventajas. Por ejemplo, depende del criterio que hayan usado para definir las interfaces (una por caso de uso, una por controlador, algo intermedio). Por otra parte, si se utilizan manejadores para las colecciones, en lugar de tenerlas en los controladores, es posible que no se presenten algunos de estos problemas.

Notar que este tema no se evalúa en parciales y exámenes de Programación 4. Posiblemente retomen esto en otros cursos de la carrera, utilizando otros paradigmas y tecnologías de desarrollo.

Saludos