Clase del 25/09/2007 (Diseño Avanzado con Objetos)

Polimophic Hierarchy - Subimplementor methods are the key

La utilización consistente de métodos polimórficos lleva a las clases polimórficas y finalmente a la jerarquía polimórfica. Reuso de descripciones de métodos: Cuando se está redefiniendo un método definido en su jerarquía de clases, sus descripción debería ser “See superimplementor”, ya que el comportamiento de dicho método será igual al de su superclase, aunque su implementación sea distinta. Además debería ser definido en el mismo protocolo que en su jerarquía. De esta manera cuando se escriben todas las implementaciones de dicho mensaje, habrá solo una descripción, y la misma se encontrará en el método de la superclase que define la jerarquía. El mismo principio se aplica al habito, en Smalltalk, de que un método simple llame a otro método, que usualmente tendrá el mismo nombre, pero con parámetros extras. En dichos casos no es necesario describir el propósito de todos estos métodos.

Anatomía de la descripción de métodos:

La descripción de un método debería dividirse en el propósito del método y los detalles de su implementación. El propósito explica lo que el método hace. Los detalles de la implementación son opcionales y se utilizan para describir ciertas decisiones de implementación. El propósito del método es reusable para todas las implementaciones del mensaje en la jerarquía, mientras que los detalles de implementación no lo son, ya que si dos implementaciones del mismo método tuvieran los mismos detalles de implementación, estarían duplicando códigos.

Reuso de la descripción para el polimorfismo:

No se puede pensar en una clase sin entender a su superclase. La superclase debe hacer casi todo, la subclase debe conocer cómo hacerlo. Cada método que subimplementa la subclase debe hacer lo mismo que hace el método en la superclase. No debe hacerlo de la misma forma, pero debe producir el mismo resultado. Es decir debe tener el mismo propósito. Cuando todas las implementaciones en la jerarquía tienen el mismo propósito, ellos son polimórficos, y tenemos una jerarquía polimórfica. Para que dos métodos sean polimórficos, no solo deben tener el mismo nombre sino también deben comportarse de la misma manera, es decir que deben producir los mismos efectos, tener los mismos tipos de parámetros y el mismo tipo de retorno. Dos clase polimórficas entienden los mismos mensajes, y sus implementaciones son polimórficas. Dos clases no siempre comparten la misma interfaz completa, pero pueden compartir la interfaz central (the core interface) y seguir siendo polimórficas. La interfaz central (core interface) es la interfaz que comparten algunas clases, por la cual pueden ser intercambiables. Mientras se usen las colaboraciones de dicha interfaz, se puede usar cualquier instancia que posea dicha interfaz. Cuando las jerarquías son polimórficas, son más flexible, extensibles, reusables y fáciles para entender.

Template Class Pattern:

La clase abstracta que define una jerarquía polimórfica, es lo que se llama “Template Class”. El patrón Template Class es utilizador para crear jerarquías polimórficas. La clase Template define la interfaz para una clase (nuevo tipo) y deja los detalles de implementación para sus subclases.

Patterns Generate Arquitectures:

Los patrones de diseños fueron propuestos como una manera de comunicar decisiones de diseño. Una arquitectura es la manera en la cual las partes trabajan en conjunto para formar el todo. Un framework es un diseño reusable para un sistema o parte de un sistema expresado en un conjunto de clases abstractas y la manera en que colaboran las instancias de dichas clases. Es una solución de diseño/arquitectura para un problema específico. Los frameworks son una manera particular de representar arquitecturas. Ambas ideas están referidas al reuso de diseños. Otra de las ideas referidas al reuso de diseños, son los patrones. Los patrones proveen un lenguaje común para los diseñadores que facilita hablar sobre diseños y documentarlos. Otra de las ventajas que poseen es que los diseñadores menos expertos pueden usarlos y proveer una base lógica de sus diseños. Algunos patrones pueden ser genéricos y otros pueden ser específicos para un dominio de aplicación.

Cada patrón tiene el siguiente formato: • Precondición: Los patrones que deben ser satisfechos antes que dicho patrón sea válido. • Problema: Un resumen del problema al cual está dirigido el patrón. El problema debe ser usado por el lector, para ver si el patrón es aplicable o no. • Restrincciones (constraints): Las restricciones describen el conflicto de cualquier solución al problema. • Solución: Un resumen de la solución al problema. La solución generalmente está acompañada por diagramas.

Describir una arquitectura con patrones es como el proceso de división de células y especialización que conducen al crecimiento del organismo biológico. El diseño comienza como una nube confusa que representa el sistema a realizar. Cuando los patrones se comienzan a aplicar a dicha nube, se comienza a focalizar las distintas partes del sistema. Cuando no hay más patrones a ser aplicados, el diseño está terminado. El paper da como ejemplo de derivación de arquitecturas a través de patrones, la arquitectura de HotDraw, un framework para estructurar editores gráficos. Para dicha arquitectura, utiliza los siguientes patrones: • Model – View – Controler: para mostrar y manipular los dibujos en la pantalla. • Controler: para representar el concepto de figuras. • Objects of State: para representar que herramienta es seleccionada en la paleta (ya que dicho comportamiento depende del input). • Editor: para representar que diferentes tipos de dibujos necesitarán diferentes conjuntos de herramientas. • Observer: para actualizar la imagen en la pantalla cuando las figuras cambiaron su apariencia. • Collect Damage: para representar que cuando algunas partes del dibujo cambian simultáneamente, queremos que se actualicen como una unidad. • Update as User Speed: para asegurarnos que se muestren los cambios colectados con el patrón Collect Damage (región damaged). • Wrapper: para manejar los “handles” de la figuras.

Conclusiones:

La derivación de una arquitectura a partir de patrones es como la presentación de un teorema matemático. Comenzando con un problema a resolver, se van usando pasos conocidos para ir refinando la solución. E resultado es que no solo se entiende el sistema final sino también se entienden las razones que conducen a él. Por todo esto en sencillo para los programadores usar y extender sistema documentados con la derivación a través de patrones.