13 de diciembre de 2014

Introducción a los Patrones de diseño

Artículo original: Introduction to Design Patterns
http://weblogs.foxite.com/andykramek/2006/12/02/introduction-to-design-patterns/
Autor: Andy Kramek
Traducido por: Ana María Bisbé York


¡ Cuánto tiempo !

Hace ya tiempo que no he podido actualizar mi blog y existen varias razones para ello, no solamente se debe a que he estado extremadamente ocupado profesionalmente, trabajando en varios proyectos interesantes. Más recientemente, Marcia y yo viajamos a Frankfurt a hablar en la 13ra European DevCon donde nos unimos a Craig Bernston, Doug Henning, Lisa Slater-Nicholls y Rick Schummer.

Esta fue, como siempre, una G R A N conferencia y mantuvo el misterio de siempre, para todos nosotros los que hemos presenciado este evento, la poca cantidad de personas de EEUU que han estado. Los vuelos son (relativamente) baratos y agradables, y la oportunidad de presenciar una conferencia genuinamente buena combinado con un descanso europeo y recreación, es sencillamente una buena idea. Puede encontrar detalles de lo que se perdió en varios lugares de la red, incluyendo la cobertura en Universal Thread y los blogs de algunos presentes como Craig, Doug y Rick.

Tengo en plan comenzar otra pequeña serie de artículos en mi blog, justo ahora, con el tema de patrones de diseño. Esto es algo que me interesa desde hace ya tiempo (vea "The Revolutionary Guide to Visual FoxPro OOP", Wrox Press, 1996 escrito por Will Phelps, Bob Groomes y yo, con algunos ejemplos iniciales basados en patrones de diseño con VFP), y a juzgar por los comentarios y discuciones que he presenciado en conferencias, no soy el único interesado. La pregunta más común que he escuchado es "¿Cómo utilizo los Patrones de diseño en VFP?" y esto es lo que trataré de enfocar con esta pequeña serie de artículos - al menos para algunos de los patrones más comunes.

¿Porqué me debo preocupar por los Patrones de diseño?

Los patrones de diseño ofrecen un lenguaje estándar para reconocer, definir, y describir soluciones a problemas de la creación de aplicaciones. El conocimiento de los patrones de diseño, hace más fácil entender los sistemas existentes y describir los requerimientos para nuevos sistemas complejos.

Recuerdo que hace unos años, sentado con Paul Maskens en el lobby de Lindner Conference Hotel en Frankfurt, mientras el me explicaba una idea para la columna Kitbox. El estaba describiendo una solución a un problema que había desarrollado y luego de aproximadamente 20 minutos, de pronto, me di cuenta de que estaba hablando de el "patrón de estrategia". El comenzó diciendo que había implementado el patrón de estrategia quise saber inmediatamente qué uso general tenía aquí, y el método que había empleado para solucionarlo. Esto nos ahorró mucho tiempo y esfuerzo y nos permitió concentrarnos en los detalles de la implementación.

Sin embargo, es importante indicar que los patrones de diseño, no son, de por sí, la solución a problemas específicos. Son vías sencillas de identificación de los problemas y una descripción genérica de soluciones, que han sido probadas por la experiencia. La implementación real de los patrones de diseño sigue siendo el trabajo de un desarrollador de aplicaciones.

¿Qué son patrones de diseño?

Antes de comenzar a bucear en ejemplos específicos de cómo implementar patrones de diseño específicos en Visual FoxPro, debo comenzar por definir qué entendemos por "Patrones de Diseño". Se han propuesto varias definiciones y quizás la más reconocida es la que aparece en el trabajo "Design Patterns, Elements of Reusable Object-Oriented Software" (Diseño de patrones, elementos de reutilización de aplicaciones orientadas a objetos) escrito por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides (comúnmente conocidos por la pandilla de los cuatro o simplemente como "GoF"). Ellos ofrecen, en el primer capítulo de su libro "What is a Design Pattern" (¿Qué es el diseño de patrones?), la siguiente definición:

Un diseño de patrones nombra, abstrae e identifica los aspectos claves de una estructura de diseño común que lo hace útil para la creación de un diseño orientado a objetos reutilizables. El diseño de patrones identifica la participación de clases e instancias, sus roles y colaboraciones, y la distribución de responsabilidades.

Esta es una buena definición, porque encapsula los cuatro elementos de cualquier diseño de patrones.

  • Tiene un nombre. Esto es vital, porque permite a los desarrolladores superar uno de los problemas fundamentales del diseño de aplicaciones – cómo comunicar lo que haces a otros? El ejemplo de Paul y yo discutiendo una idea para un artículo, que he mostrado antes, ilustra este punto perfectamente.
  • Abstrae el problema. Esto es referido por "GoF" como el "objetivo". Nos dice la naturaleza del problema y la solución descrita por el patrón. Considere el problema frecuente de advertir a los usuarios de no crear múltiples instancias de una aplicación. Los usuarios, por lo general, tratan de comenzar nuevas instancias de la aplicación porque, al tener minimizada la pantalla principal, se olvidan que está activa y hace clic en el icono del escritorio, en lugar de de maximizar la instancia existente. Podemos ver inmediatamente que el patrón Singleton es relevante porque su objetivo es "Asegurar una clase que tiene una sola instancia y provee un punto global de acceso a ella".
  • Define una estructura de diseño. Es importante darse cuenta que los patrones de diseño no ofrecen soluciones a los problemas. Ellos describen estructuras que permiten solucionar un problema de manera que resulte más fácil de reutilizar que si se escribe simplemente el código para solucionar el problema en el contexto en el que surge. Todos hemos pasado por estas experiencias de darnos cuenta que hemos solucionado ya un problema particular en algún lugar en nuestro código, pero no podemos re-utilizarlo, porque no hicimos una solución aislada de la situación. El objetivo de los patrones de diseño es ayudarnos a reconocer situaciones como estas y evitarlas.
  • Identifica la distribución de responsabilidades. Esto es, por supuesto, la clave a todos los tópicos de diseño y no está limitado a los patrones de diseño. Después de todo, una vez conocido lo que tiene que hacer una clase (u objeto), escribir el código para hacerlo es relativamente fácil. La ventaja de los patrones de diseño es que una vez que haya reconocido el problema y lo haga corresponder con un patrón, el patrón nos dirá cómo debemos asignar las responsabilidades y por consiguiente nos ayudará a crear rápidamente le "mejor" solución.

No es mi intención ofrecer una revisión exhaustiva de todos los patrones de diseño conocidos (existen libros enteros dedicados a eso). Pero en esta pequeña serie mi plan es cubrir los patrones encontrados más frecuentemente y mostrar cómo puede utilizar el Visual FoxPro para implementar una solución. Cada artículo es independiente y cubrirá un patrón, aunque intentaré en lo posible mantener un hilo único en ellos.

Espero que encuentre útil esta información, y si tiene cualquier comentario, por favor, sea libre de publicarlo.

5 de diciembre de 2014

Cualquier dirección con StreetView !!!

Artículo original: StreetView any address !!!
http://vfpimaging.blogspot.com.br/2014/12/streetview-any-adress.html
Autor: Cesar VFPIMAGING
Traducido por: Luis María Guayán


Acabo de recibir un pedido de un usuario que le permita ver la Vista de la Calle (Google StreetView) de nuestros clientes en los formularios de clientes.

Esto es útil especialmente para los casos de entregas, lo que permite al equipo saber el aspecto de la calle, y planificar mejor las entregas de mercaderías.

He encontrado varios ejemplos, pero todos ellos necesitaba las coordenadas GPS (Global Positioning System - Sistema de Posicionamiento Global), la latitud y la longitud para hacer que funcione.

Después de hacer algunas búsquedas, he encontrado la solución en el BLOG JAYCODE DESIGN, de Jordan Clist.
"A todos nos gusta el servicio Streetview que ofrece Mapas de Google. Naturalmente, la API de Google ofrece la posibilidad de incrustar Streetview dentro de una aplicación web, si le das los datos y coordenadas correctas.
Lo qué no hace de forma natural y fácil es apuntar la cámara StreetView automáticamente a una dirección.
Esto es algo que pensé que sería fácil, pero en realidad era más difícil de lo que parece.
Aunque es bastante simple crear una vista panorámica de la calle en un punto GPS dado, lo que es más complicado es asegurarse de que la cámara StreetView esté apuntando en la dirección correcta (punto de vista, u orientación)"
Por lo que es el trabajo era un poco complicado, ya que el ejemplo original proporcionado trabajó solamente con algunas direcciones ya conocidos por Google. Eso hizo que falle en la mayoría de los casos, debido a la ortografía, o incluso una coma puesta en el lugar equivocado.

Así que usé otra API de Google Maps, la "Google Maps Directions API", que se utiliza originalmente para decirnos las rutas que podemos tomar entre 2 direcciones. Esta API funciona muy bien con las direcciones sin un buen formato, y devuelve la versión de Google de la dirección. Adapté un ejemplo de Mike Gagnon, de su artículo publicado en http://atoutfox.org "Calcular la distancia entre 2 direcciones, y mostrar el recorrido completo"

Después de conseguir esta dirección, lo paso al script  de Jordan Clist y Voila! Funciona !

Copiar y pegar el siguiente código y guardarlo en un archivo .PRG y llamado "GOOGLESTREETVIEW.PRG"

Y para probarlo, escriba en la ventana de comandos:

=GoogleStreetView("Arche du Triumph") 

o, por supuesto, pasando la dirección completa:

=GoogleStreetView("Place Charles de Gaulle, 75008, Paris, France")

Bonito no es así?



1 de diciembre de 2014

Diseñar y crear clases

Artículo original: Designing and Building Classes
http://weblogs.foxite.com/andykramek/2005/03/27/designing-and-building-classes/
Autor: Andy Kramek
Traducido por: Ana María Bisbé York


He aquí otro tema sobre el que he sido preguntado con frecuencia y es precisamente cómo se deben diseñar las clases. Por supuesto, no hay una única respuesta "correcta"; pero he encontrado siempre muy útil al crear una clase nueva, preguntarme estas tres preguntas:

  • ¿Será reutilizado el objeto?
  • ¿La clase va a simplificar la tarea o a complicarla?
  • ¿Vale la pena el esfuerzo?

Ahora, para ganar en claridad, permítanme que me expanda un poco en esto:

Re-usabilidad

Este es, probablemente la razón más común para la creación de una clase y la posibilidad de re-utilizarla, es después de todo, uno de los logros primarios de POO. En su nivel más simple, puede significar tan sencillo como establecer sus preferencias a los objetos - propiedades Font, Color y Style, por ejemplo, de tal forma que todos los objetos de sus clases se creen con la configuración correcta. Las cosas se complican un poco cuando consideramos la funcionalidad. En la práctica, ¿con qué frecuencia hacemos exactamente lo mismo, en exactamente la misma forma, para alcanzar exactamente el mismo resultado? La respuesta es probablemente "no muy frecuentemente" y empezará a asombrarse si la re-usabilidad, es después de todo, realmente tan valiosa. Pasemos al segundo criterio.

Controlar complejidad

Realmente es muy raro que las clases funcionales puedan simplemente ser re-utilizadas "tal cual". Existen casi siempre, diferencias en el entorno, la entrada o salida de datos requeridos y a veces, todos juntos. Esta complejidad aparente puede a veces oscurecer el tema, con la funcionalidad que se desea mantener constante, incluso a través de la implementación, puede diferir en detalle entre las aplicaciones.

Al aplicar las reglas para el diseño de clases resumidas en el siguiente tópico, debe ser más fácil decidir si al utilizar una clase va a facilitar el control de esta complejidad o no. Incluso, si el criterio de una clase pueda facilitar la manipulación de la complejidad, nosotros aun tendremos que considerar el tercer criterio.

Vale la pena el esfuerzo

Un objeto debería ser encapsulado para que contenga en si mismo toda la información necesaria para completar su tarea, e incluso evidente que ningún objeto debe confiar su implementación interna a otro objeto. Claramente esto puede complicarnos mucho la vida. Puede significar que su clase tendrá que verificar docenas de condiciones posibles para determinar (para si) exactamente que el estado del sistema es antes de que pudiera realizar la función asignada. Al considerar la creación de una clase nueva, es importante estar seguros de que realmente vale la pena el esfuerzo de hacer tal cosa.

¿Qué tipo de clase queremos?

Al tener que decidir que realmente deseo crear una clase nueva, la siguiente pregunta a responder es: ¿Qué tipo de clase debo diseñar?" Existen dos modelos fundamentales para el diseño de clases que son el "Mundo Real" o un modelo concreto de "Componente" o modelo abstracto. No hereda uno del otro, son precisamente diferentes.

Modelo Mundo real (concreto)

En este modelo las clases se diseñan para cumplir la funcionalidad requerida en su totalidad. En este modelo se basan usualmente los Objetos de negocio. Por ejemplo, podemos definir a una clase objeto de negocios "persona" que tiene las características comunes (por ejemplo, propiedades para Ojo izquierdo, ojo derecho, nariz, etc) y el comportamiento de las personas (ejemplo Métodos de Respiración, Alimentación, etc). Esta clase persona puede ser sub-claseada para modelar la funcionalidad de tipos especiales de personas tales como "clientes" o "amigos". Es realmente aparente que el modelo real confía demasiado en la herencia y , como un resultado, en tiempo de diseño, está explícitamente definida la funcionalidad  .

Modelo Componente (abstracto)

En este modelo la clase se ocupa más de un comportamiento específico, que de funcionalidad. Cada clase define una función genérica o acción y, de manera aislada, limita la usabilidad. Claramente habrá más confianza en la herencia, en su lugar, el modelo va a depender de la agregación (esencialmente una operación en tiempo de ejecución) y la composición (en tiempo de ejecución y diseño). El equivalente para nuestra clase objeto de negocio Persona es un compuesto de objetos separados: dos instancias para las clases ojos y una instancia para la clase nariz, etc.

Identificar responsabilidades

Habiendo decidido qué modelo va a utilizar. la siguiente tarea es estar absolutamente seguro de que sabe lo que la clase va a hacer. Esto puede sonar obvio; pero hay una trampa sutil en esto. Es muy fácil crear demasiado en una clase, antes de que se de cuenta que lo que ha creado que en realidad no es re-utilizable, porque hace demasiado. El mejor proceder para esto es identificar y categorizar las "Responsabilidades" de la clase antes de que comience a escribir código alguno. Una responsabilidad puede estar definida, de forma muy simple, como algún elemento de funcionalidad que tiene que ser completado.

Categorizar responsabilidades (Las reglas "debe, podría haber y debe ser hecho").

El propósito de la categorización es asegurarse de que puedo identificar correctamente donde en la jerarquía de clases, pertenece cada responsabilidad. Yo hago esto al utilizar tres categorías las que llamo "debe hacer", "podría hacer" y "debe ser hecho"

Las responsabilidades que caen dentro de la primera categoría "debe hacer" son aquellas que derivan de un objeto desde la clase que debe hacer en cada situación y que no puede ser hecho por otro objeto. Esto es, claramente, la responsabilidad de la clase. Debe ser parte de la definición de clase raíz. Por ejemplo, cualquier objeto que mueve el puntero del registro en una tabla, cursor o vista, DEBE chequear las condiciones EOF() y BOF().

Las responsabilidades que entran en la categoría "podría hacer" son indicadores de que la clase puede requerir una o más subclases (o, posiblemente, la cooperación entre objetos de otra clase.) En otras palabras, estas son cosas que es posible que haga la clase; pero que no son precisamente requeridas en cada situación. Típicamente es un fallo reconocer aquí estos elementos que "podría hacer" muy pronto en el proceso de diseño que encamine a una inadecuada colocación de la funcionalidad en la jerarquía de clases y la selección sea hecha. Sin embargo, un objeto que muestre una lista PUEDE inhabilitarse a si mismo una vez que sea hecha la selección. Sin embargo, esto no es la función esencial y no es el comportamiento requerido en cada momento. Esto pertenece a una subclase especializada.

La categoría final (debe ser hecho) es muy importante también. Esta es la categoría que define la suposición de que una clase puede ser exitosa para funcionar correctamente. Los elementos listados definitivamente no son de única responsabilidad de la clase en cuestión pero pueden, aun así, ser hechos de alguna forma. Por ejemplo, para que un control enlace con un origen de datos, el origen de dato DEBE estar abierto antes de que sea instanciado el control. Sin embargo, controlar esta operación claramente no es responsabilidad del control como tal - si solamente porque debe estar hecho antes de que se instancie el control.

Teniendo definidas y categorizadas las responsabilidades de la nueva clase, puede entonces definir su interfaz pública decidiendo qué propiedades y métodos va a requerir y cómo se deben revelar a otros objetos con los que interactúan. Sólo cuando todo esto esté hecho, puede comenzar a pensar sobre el código y aquí hay un par de cosas que es necesario recordar.

Escribir código en los métodos, no en los eventos.

Al escribir el código de las clases, yo creo firmemente en evitar el colocar código directamente en los eventos nativos de Visual FoxPro, siempre que puedo hacerlo. En su lugar, creo métodos de usuario y los llamo desde los eventos. Hacerlo sí no es, admitámoslo, un requerimiento; pero encuentro que te facilita la vida por varias razones:

  • Me permite dar nombres más identificativos a los métodos. Esto puede sonar trivial; pero realmente hace que sea más fácil de leer y mantener el código cuando el código produce algún tipo de salida es llamado por: "This.GenerarSalida()" en lugar de "Thisform.Pageframe1.Page1.CmdButton1.Click()"
  • Me permite cambiar la interfaz, si es necesario con la simple re-colocación de una única línea que llama al método en lugar de de tener que cortar y pegar la parte funcional del código.
  • Me permite partir los métodos complejos en métodos múltiples (y potencialmente reutilizables). El evento actúa meramente como indicador para el código asociado.

Los métodos deben hacer una cosa y sólo una

Los métodos que hacen "de todo" son difíciles de reutilizar. Recuerde: una simple línea de código es siempre reutilizable. Si tengo que oprimir la tecla Re Pag más de una vez para ver mi código, lo más probable es que el método sea demasiado largo y trate de hacer demasiadas cosas. La solución es partir ese tipo de métodos monolíticos en métodos pequeños y mejor enfocados, y utilizar un método de control que los pueda llamar de forma individual si es necesario. (Pregúntese a si mismo cuántas veces se ha visto duplicando código en un método o bloque de código que ya existe en parte de otro método.

Asegúrese de poner la funcionalidad lo más alto posible en la jerarquía de clases

Esto es una trampa en la que he caído muchas veces a través de los años y aun ocasionalmente tropiezo. Debe saber que cuando coloca funcionalidad muy alto porque invierte mucho tiempo en sus subclases tratando de lograr toda una gran funcionalidad que pueda en la clase raíz. Uno de los mayores beneficios de esto "Puede, debe, podría" es el que ayuda a evitar esta trampa.

Utilice métodos plantilla para una interfaz inconsistente.

He constatado que necesitamos evitar colocar la funcionalidad en una jerarquía muy alta. Al crear un contenedor, vacío métodos en un nivel más alto de la jerarquía, puedo asegurar que todas las clases van a compartir una interfaz común. Ya que las subclases comparten la interfaz común, son intercambiables. Incluso, si un método vacío es llamado., no hace daño a nadie, porque todos los métodos de VFP devuelven .T. de forma predeterminada, incluso si no contienen texto.

22 de noviembre de 2014

Domine Visual FoxPro 9.0 SP2 / Expert in Visual FoxPro 9.0 SP2


Español

Comparto con Uds. un libro que termine de escribir de Visual FoxPro 9 SP2. NUEVO: Agregué la versión en inglés

Para leer el libro Domine Visual FoxPro 9.0 SP2 en formato PDF en español (2,16 MB) haga clic aquí.
Nota: Para descargar el libro haga en español haga clic derecho aquí y seleccione la opción "Guardar destino como"

Atte. Ernesto Fabián Coronel

Agradecimientos:

  • Agradezco a mi familia por siempre, por apoyarme en el tiempo que no les dedique, por estar abocado en mi "proyecto de escribir este libro".
  • A mi esposa Julia e hijos: Igor, Ernesto y Cristina.

English

I share with you a book to finish writing Visual FoxPro 9 SP2. NEW: I added the English version

To read the book Expert in Visual FoxPro 9.0 SP2 in English in PDF format (2.16 MB) click here.

Note: To download the book done in English right-click here and select "Save Target As"

Sincerely, Ernesto Fabián Coronel

Acknowledgments:

  • I thank my family for always, for supporting me in the time not devoted to them, being doomed in my "project of writing this book."
  • My wife Julia and children: Igor Ernesto and Cristina.