Screencast: Replace conditional, Part II

This is the second part of the "Replace conditional with polymorphism" screencast, where I kept using the Command and Template Method design patterns. This time we see how a base controller class emerges from refactoring.

Nota: En los tests del controller que se muestran en el video hay un inconveniente y es que al usar " hardcoded json" como dato de entrada, puede haber bugs en el propio test. En una version posterior a este screencast, usamos el Translator para generar el json por nosotros en estos tests, ya que hay otro TestCase para los casos de serializacion-deserializacion. Es decir, hubo un refactor de tests.

Lectura adicional recomendada: Pensando en Generics

¿Te gustaría patrocinar el próximo screencast? Just let me know! 🙂

Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • http://programacionsolida.blogspot.com Juan Barrionuevo

    Luego de haber visto ambos videos, me surgen dos preguntas.
    a.- Conviene agregar a los colaboradores de las clases en sus respectivos constructores y así obligar a que al instanciar dichas clases se les pase una instancia de los mencionados colaboradores?

    b.- Para evitar el case final del factory. Convendría tener un diccionario del tipo para así acceder directamente al Command deseado?

  • http://programacionsolida.blogspot.com/ Juan Barrionuevo

    Otra cosa que olvidé mencionar en el comentario anterior:
    Estos videos resultan muy interesantes, ilustrativos y educativos.
    Muchas gracias Carlos por tomarte las molestias de crearlos.

  • http://www.carlosble.com Carlos Ble

    Hola Juan! Gracias por tu feedback, es de las mejores cosas de publicar.
    Te respondo:

    a – En general prefiero inyectar dependencias por constructor pero a veces me conviene mas por setter. Depende del framework que tenga que usar. Ambas opciones tienen sus pros y contras. Tenemos una factoria que crea objetos usando reflection y para eso es mas facil si tienen un constructor vacio por defecto. Igual pasa cuando se usan frameworks de IoC como Spring.

    b – Igualmente en algún sitio hay que tener esa lógica de saber qué valor se asigna a cada clave del diccionario y podria haber bugs en ella. Generalizar a un diccionario en este punto me parecería demasiado complejo para lo que necesito.

    Ten en cuenta que el código de los videos sigue siendo mejorable y que algunas partes son legadas. El código nunca es perfecto, siempre puede evolucionar o degenerar. En mi opinion.

  • http://programacionsolida.blogspot.com Juan Barrionuevo

    Carlos, Muchas gracias por tu respuesta.
    Luego de 15 años de ser programador, no dejo el camino del aprendizaje, de ahí, mis preguntas.
    Vengo de la vieja escuela “procedural” y mejorar mi “OOP” cada día, es mi objetivo.
    Otra vez gracias por tu tiempo y por seguir compartiendo tus conocimientos.

  • http://www.carlosble.com Carlos Ble

    Gracias de veras a ti por el feedback. Todos vamos aprendiendo, yo espero no dejar de hacerlo. Pronto quisiera grabar un nuevo screencast mejorando la tecnica empleada en el primero 🙂
    Saludos cordiales