La forma de solucionar problemas utilizando técnicas de Orientación a Objetos es muy distinta de la forma tradicional o estructurada. Cuando nos presentan un requerimiento de una nueva aplicación y queremos emplear los conceptos de la Programación Orientada a Objetos, como primer paso nos concentraremos en identificar los objetos que intervienen en el problema. Deberemos, entonces, analizar cuidadosamente el requerimiento, hablar con los usuarios y prestar especial atención a los elementos que mencionan. Una técnica muy usada consiste en leer el requerimiento escrito (que deberá ser lo más claro y completo posible) y subrayar todos los sustantivos, tanto concretos como abstractos. Luego, de entre todos los sustantivos subrayados, descartamos aquellos que no son propios del problema por resolver. Una vez realizada esta primera actividad, habremos identificado una buena parte de los objetos del dominio de la aplicación.
Por ejemplo, imaginemos que necesitamos implementar una aplicación de alquiler de autos, y nos presentan el siguiente requerimiento (resumido): La empresa dispone de autos para alquilar a sus clientes. Cuando se alquila un auto, el cliente firma una póliza de seguro. En un formulario de alquiler, se registra la fecha, el nombre del cliente, el número de su registro de conductor y el número de tarjeta de crédito.
Si aplicamos la técnica de los sustantivos, podremos identificar rápidamente tres objetos fundamentales para la aplicación: auto, cliente y formulario de alquiler. Dependiendo del tipo de análisis y diseño que queramos hacer, podríamos considerar como objetos la tarjeta de crédito e, incluso, el alquiler.
Como decíamos al principio, los objetos poseen propiedades y comportamiento. Para identificar las propiedades aplicamos una técnica similar a la de los sustantivos, pero buscando cualidades o adjetivos de los objetos que ya hemos identificado. Siguiendo con el ejemplo del alquiler de autos, podemos ver que el formulario de alquiler tiene propiedades como la fecha, el nombre del cliente, etcétera.
Una vez que hemos identificado los objetos y sus propiedades, estamos en condiciones de definir clases para agruparlos y abstraer todas las posibles instancias de ellos. Hemos alcanzado así el fin de la primera etapa en el proceso de solución de problemas mediante técnicas de orientación a objetos.
TOMARLO CON CALMA
Muchas veces, no lograremos identificar con claridad todos los objetos en una primera lectura. Será necesario hacer una segunda pasada (incluso más) sobre el texto del requerimiento para encontrar objetos ocultos, despejar ambigüedades o
eliminar falsos objetos que no son esenciales para la solución concreta del problema.
PATRONES DE DISEÑO
Si bien el proceso de análisis y diseño orientado a objetos se centra en la identificación de los objetos propios del dominio del problema, a menudo es necesario crear objetos ficticios. Éstos colaboran con los objetos reales en la solución del problema o en proveer mecanismos de flexibilidad, extensibilidad o claridad del código, y ayudan a separar los intereses y responsabilidades de cada objeto. Un ejemplo muy común de estos escenarios son los requisitos no funcionales.
Para entender un poco mejor este aspecto, retomemos el ejemplo del sistema de alquiler de autos e imaginemos que se nos exige que el sistema valide la tarjeta de crédito, pero que además el código esté preparado para adaptar el sistema a nue vos mecanismos de validación. Una posible solución es definir una clase llamada ValidadorTarjetaCredito, con un método que reciba un número de tarjeta y un importe, y valide que se puede cobrar ese importe a esa tarjeta. Luego, utilizando la herencia y el polimorfismo (que veremos luego), se pueden crear nuevas clases que empleen diversos mecanismos de validación.
A lo largo de los años, los desarrolladores reconocieron que muchas de las solu- ciones que encontraban a los problemas no funcionales con orientación a objetos comenzaban a repetirse o tenían elementos en común y que, además, funcio- naban (es decir, cumplían su propósito). Actualmente, a estas soluciones proba- das a problemas comunes, se las llama patrones. Hay distintas clasificaciones de patrones según la familia de problemas que atacan, siendo los más comunes los denominados Patrones de diseño.
El principal objetivo de los Patrones de diseño es el de proveer un catálogo de elementos de diseño que ayuden a los programadores en su tarea diaria, evitando que tengan que buscar nuevas soluciones cada vez que se enfrentan con un problema común. Además, los Patrones de diseño facilitan la comunicación entre los programadores, como así también la comprensión del código escrito por otro. Obviamente, los patrones no pretenden eliminar el trabajo del desarrollador, ya que éste debe ser capaz de identificar las características de cada problema y tener un dominio de los principales patrones para asociarlos con el problema y aplicarlos.
LA BANDA DE LOS CUATRO
El tema de los patrones ha generado gran cantidad de bibliografía. Quizá el libro más popular a la hora de aprender sobre patrones es Design Patterns. Elements of Reusable Object-Oriented Software . Los patrones que en él se presentan, se conocen como patrones GoF, sigla de Gang of Four (la Banda de los Cuatro), en alusión a sus cuatro autores, autoridades absolutas en este ámbito (Gamma, Helm, Jonson y Vlissides).
Por ejemplo, imaginemos que necesitamos implementar una aplicación de alquiler de autos, y nos presentan el siguiente requerimiento (resumido): La empresa dispone de autos para alquilar a sus clientes. Cuando se alquila un auto, el cliente firma una póliza de seguro. En un formulario de alquiler, se registra la fecha, el nombre del cliente, el número de su registro de conductor y el número de tarjeta de crédito.
Si aplicamos la técnica de los sustantivos, podremos identificar rápidamente tres objetos fundamentales para la aplicación: auto, cliente y formulario de alquiler. Dependiendo del tipo de análisis y diseño que queramos hacer, podríamos considerar como objetos la tarjeta de crédito e, incluso, el alquiler.
Como decíamos al principio, los objetos poseen propiedades y comportamiento. Para identificar las propiedades aplicamos una técnica similar a la de los sustantivos, pero buscando cualidades o adjetivos de los objetos que ya hemos identificado. Siguiendo con el ejemplo del alquiler de autos, podemos ver que el formulario de alquiler tiene propiedades como la fecha, el nombre del cliente, etcétera.
Una vez que hemos identificado los objetos y sus propiedades, estamos en condiciones de definir clases para agruparlos y abstraer todas las posibles instancias de ellos. Hemos alcanzado así el fin de la primera etapa en el proceso de solución de problemas mediante técnicas de orientación a objetos.
Con las técnicas de análisis, identificamos los objetos del mundo real; luego abstraemos sus propiedades para agruparlos en clases.
TOMARLO CON CALMA
Muchas veces, no lograremos identificar con claridad todos los objetos en una primera lectura. Será necesario hacer una segunda pasada (incluso más) sobre el texto del requerimiento para encontrar objetos ocultos, despejar ambigüedades o
eliminar falsos objetos que no son esenciales para la solución concreta del problema.
PATRONES DE DISEÑO
Si bien el proceso de análisis y diseño orientado a objetos se centra en la identificación de los objetos propios del dominio del problema, a menudo es necesario crear objetos ficticios. Éstos colaboran con los objetos reales en la solución del problema o en proveer mecanismos de flexibilidad, extensibilidad o claridad del código, y ayudan a separar los intereses y responsabilidades de cada objeto. Un ejemplo muy común de estos escenarios son los requisitos no funcionales.
Para entender un poco mejor este aspecto, retomemos el ejemplo del sistema de alquiler de autos e imaginemos que se nos exige que el sistema valide la tarjeta de crédito, pero que además el código esté preparado para adaptar el sistema a nue vos mecanismos de validación. Una posible solución es definir una clase llamada ValidadorTarjetaCredito, con un método que reciba un número de tarjeta y un importe, y valide que se puede cobrar ese importe a esa tarjeta. Luego, utilizando la herencia y el polimorfismo (que veremos luego), se pueden crear nuevas clases que empleen diversos mecanismos de validación.
A lo largo de los años, los desarrolladores reconocieron que muchas de las solu- ciones que encontraban a los problemas no funcionales con orientación a objetos comenzaban a repetirse o tenían elementos en común y que, además, funcio- naban (es decir, cumplían su propósito). Actualmente, a estas soluciones proba- das a problemas comunes, se las llama patrones. Hay distintas clasificaciones de patrones según la familia de problemas que atacan, siendo los más comunes los denominados Patrones de diseño.
El principal objetivo de los Patrones de diseño es el de proveer un catálogo de elementos de diseño que ayuden a los programadores en su tarea diaria, evitando que tengan que buscar nuevas soluciones cada vez que se enfrentan con un problema común. Además, los Patrones de diseño facilitan la comunicación entre los programadores, como así también la comprensión del código escrito por otro. Obviamente, los patrones no pretenden eliminar el trabajo del desarrollador, ya que éste debe ser capaz de identificar las características de cada problema y tener un dominio de los principales patrones para asociarlos con el problema y aplicarlos.
LA BANDA DE LOS CUATRO
El tema de los patrones ha generado gran cantidad de bibliografía. Quizá el libro más popular a la hora de aprender sobre patrones es Design Patterns. Elements of Reusable Object-Oriented Software . Los patrones que en él se presentan, se conocen como patrones GoF, sigla de Gang of Four (la Banda de los Cuatro), en alusión a sus cuatro autores, autoridades absolutas en este ámbito (Gamma, Helm, Jonson y Vlissides).