Ocurre muchas veces que percibimos la realidad y la procesamos con las herramientas que tenemos "a mano", es decir, la interpretamos utilizando comportamientos conceptuales conocidos. Cuando esto ocurre, nuestra cabeza suele hacer algún sonido (preferentemente suave que denote "click"). Por ejemplo:
El otro día fui a dejar unos trajes a la tintorería. Me pidieron que dejara un número telefónico para poder contactarme, y yo pregunté: "¿Te sirve un celular?". Acto seguido, comencé a dar el número no sin antes preguntarme: ¿Debo mencionar el 15, 11, el prefijo internacional + el prefijo de celular (en mi caso +54 9 11)?
Esto es algo que me ocurre con frecuencia, pero esta vez me dio lugar a pensar, que deberíamos dar los números indicando "Esto es un celular", y que sea un "problema" del otro, saber cómo debe llamar. De hecho, nosotros no sabemos desde dónde nos van a llamar, si desde un teléfono local, un sistema de voIP situado en otro país, o telequinéticamente. Si damos por sentado un prefijo, quien recibe la información, debería quitarlo y almacenar el número en su forma más reducida, que es finalmente, aquella que simplemente identifica el celular. Más allá del ejemplo, lo que estaba intentando hacer mi cabeza, era separar algunos componentes que iban a participar en la comunicación, ordenarlos y categorizarlos de forma tal de entender las responsabilidades de cada uno. Como resultado:
1. Existe alguien que va a intentar comunicarse conmigo.
2. Existe mi teléfono (identificable independientemente de donde sea llamado).
3. Existe una operación de marcado, que permitirá la comunicación (existen muchas formas de marcar).
En esta separación, puede apreciarse:
A. Separación de lo que cambia respecto de lo que queda fijo. (1 y 3 cambian. 2 queda fijo).
B. Hay una interfaz y una implementación (llamar, y la operación de marcado respectivamente). Es conveniente preocuparse por la interfaz, y dejar que quién llama (1) elija como hacerlo (escogiendo el método correspondiente entre los disponibles).
Estas dos apreciaciones (algo caprichosas quizas), responden a 2 principios de buen diseño orientado a objetos. Y la categorización previa (entre puntos 1, 2 y 3), identifica claramente: Contexto, Interfaz e implementación (en realidad, Teléfono como interfaz y método de marcado como implementación no es correcto, pero ayuda a entender el problema didácticamente).
Sería deseable entonces, que:
Ahora, podríamos decir: "Esto no fue para nada didáctico para comprender el strategy", y es cierto. Porque este artículo muestra como se dió el proceso en mi cabeza. Pero un enfoque realmente didáctico, sería adoptar este proceso, y simplificarlo de la siguiente manera:
1. Planteo del problema: Cuando me piden el número de celular nunca sé como darlo debido a que
2. Existen diferentes formas de llamar a un celular y la decisión debería ser tomada por alguien que conozca el
3. contexto, es decir, de dónde está llamando.
4. Diseñar una solución que me permita separar lo que cambia de lo que no, y seleccionar dinámicamente, el método a proceder dependiendo del contexto.
Es más que probable, que planteado este problema a un número de personas que estén estudiando patrones de diseño, sin saberlo, implementen strategy, comprendiendo 100% las motivaciones y dándonos lugar a entrar con la definición "by the book" como una obviedad.
El otro día fui a dejar unos trajes a la tintorería. Me pidieron que dejara un número telefónico para poder contactarme, y yo pregunté: "¿Te sirve un celular?". Acto seguido, comencé a dar el número no sin antes preguntarme: ¿Debo mencionar el 15, 11, el prefijo internacional + el prefijo de celular (en mi caso +54 9 11)?
Esto es algo que me ocurre con frecuencia, pero esta vez me dio lugar a pensar, que deberíamos dar los números indicando "Esto es un celular", y que sea un "problema" del otro, saber cómo debe llamar. De hecho, nosotros no sabemos desde dónde nos van a llamar, si desde un teléfono local, un sistema de voIP situado en otro país, o telequinéticamente. Si damos por sentado un prefijo, quien recibe la información, debería quitarlo y almacenar el número en su forma más reducida, que es finalmente, aquella que simplemente identifica el celular. Más allá del ejemplo, lo que estaba intentando hacer mi cabeza, era separar algunos componentes que iban a participar en la comunicación, ordenarlos y categorizarlos de forma tal de entender las responsabilidades de cada uno. Como resultado:
1. Existe alguien que va a intentar comunicarse conmigo.
2. Existe mi teléfono (identificable independientemente de donde sea llamado).
3. Existe una operación de marcado, que permitirá la comunicación (existen muchas formas de marcar).
En esta separación, puede apreciarse:
A. Separación de lo que cambia respecto de lo que queda fijo. (1 y 3 cambian. 2 queda fijo).
B. Hay una interfaz y una implementación (llamar, y la operación de marcado respectivamente). Es conveniente preocuparse por la interfaz, y dejar que quién llama (1) elija como hacerlo (escogiendo el método correspondiente entre los disponibles).
Estas dos apreciaciones (algo caprichosas quizas), responden a 2 principios de buen diseño orientado a objetos. Y la categorización previa (entre puntos 1, 2 y 3), identifica claramente: Contexto, Interfaz e implementación (en realidad, Teléfono como interfaz y método de marcado como implementación no es correcto, pero ayuda a entender el problema didácticamente).
Sería deseable entonces, que:
Si nos fijamos bien, y traducimos esto a un diagrama de clases UML, vamos a ver que el escenario y comportamiento, responde perfectamente a la estructura de un strategy.
Ahora, podríamos decir: "Esto no fue para nada didáctico para comprender el strategy", y es cierto. Porque este artículo muestra como se dió el proceso en mi cabeza. Pero un enfoque realmente didáctico, sería adoptar este proceso, y simplificarlo de la siguiente manera:
1. Planteo del problema: Cuando me piden el número de celular nunca sé como darlo debido a que
2. Existen diferentes formas de llamar a un celular y la decisión debería ser tomada por alguien que conozca el
3. contexto, es decir, de dónde está llamando.
4. Diseñar una solución que me permita separar lo que cambia de lo que no, y seleccionar dinámicamente, el método a proceder dependiendo del contexto.
Es más que probable, que planteado este problema a un número de personas que estén estudiando patrones de diseño, sin saberlo, implementen strategy, comprendiendo 100% las motivaciones y dándonos lugar a entrar con la definición "by the book" como una obviedad.