Patrones y Antipatrones: una Introduccin - Parte I

Por Len Welicki Artculos relacionados Patrones y Antipatrones: una Introduccin - Parte II

Contenido
Introduccin Definicin Patrones de software Caractersticas de un buen patrn Lenguajes y sistemas de patrones Niveles de patrones Pattern Happy Los patrones y la gestin del conocimiento Patrones de Diseo Principios de diseo Clasificacin de patrones de diseo Relajacin de patrones Sistemas flexibles y robustos con patrones de diseo Los patrones de diseo no son perfectos Referencias

Introduccin
El aprendizaje ms importante proviene de la experiencia directa. Nonaka & Takehuchi

El lenguaje de patrones brinda a todo el que lo utilice el poder de crear una infinita variedad de construcciones nuevas y nicas, de la misma forma que su lenguaje comn le brinda el poder de crear una infinita variedad de oraciones." Christopher Alexander

Los patrones son una disciplina de resolucin de problemas reciente en la ingeniera del software que ha emergido en mayor medida de la comunidad de orientacin a objetos, aunque pueden ser aplicados en cualquier mbito de la informtica y las ciencias en general. Los patrones tienen races en muchas reas, incluyendo la literate-programming y ms notablemente en el trabajo de Christopher Alexander en Planeamiento Urbanstico y Arquitectura Civil.

A lo largo de este artculo analizaremos brevemente el concepto de patrn y su aplicacin al software, detenindonos especialmente en los patrones de diseo, arquitectura y en los antipatrones. Es importante aclarar que este artculo no pretende ser exhaustivo, sino ms bien una introduccin a un amplio abanico de temas que sern explorados en entregas posteriores. Definicin Para comenzar, intentaremos establecer una definicin bsica del concepto de patrn. De la misma forma que sucede con otros conceptos de la informtica (y como es el caso de la arquitectura), no es fcil establecer una definicin taxativa y definitiva del concepto de patrn. De hecho, en el captulo 2 del libro Pattern Hatching [Vlissides98], John Vlissides (miembro del GoF) hace hincapi en la dificultad de esta tarea. En las diversas obras de referencia podemos encontrar diferentes definiciones. En esta seccin intentaremos reunir a las ms influyentes y significativas que nos permitan comprender la idea y establecer las bases para nuestro posterior estudio. En el libro The Timeless Way of Building [Alexander79] (obra de referencia donde se plantea por primera vez la teora de los patrones aplicada a la Arquitectura Civil y Urbanismo), el Arquitecto Christopher Alexander define al patrn en la siguiente manera: Cada patrn es una regla de 3 partes, que expresa una relacin entre un contexto, un problema y una solucin. Como un elemento en el mundo, cada patrn es una relacin entre un contexto, un sistema de fuerzas que ocurren repetidamente en ese contexto y una configuracin espacial que permite que esas fuerzas se resuelvan entre s.

Como elemento de un lenguaje, un patrn es una instruccin que muestra como puede ser usada esta configuracin espacial una y otra vez para resolver el sistema de fuerzas, siempre que el contexto lo haga relevante. Continuando con la definicin anterior, podemos agregar otro prrafo de Alexander, citado en la obra de referencia Design Patterns [GoF95] en la seccin Qu es un patrn de diseo?: Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, para describir despus el ncleo de la solucin a ese problema, de tal manera que esa solucin pueda ser usada ms de un milln de veces sin hacerlo ni siquiera dos veces de la misma forma. Para Alexander, estos patrones son ubicuos y permiten alcanzar la calidad sin nombre (Quality Without a Name QWAN). Para aclarar estas definiciones, podemos utilizar un ejemplo concreto aplicado a la construccin, tomado tambin de la obra de Alexander: Si nos fijamos en las construcciones de una determinada zona rural, observaremos que todas ellas poseen apariencias parejas (tejados de pizarra con gran pendiente, etc.), pese a que los requisitos personales por fuerza han debido ser distintos. De alguna manera la esencia del diseo se ha copiado de una construccin a otra, y a esta esencia se pliegan de forma natural los diversos requisitos. Dirase aqu que existe un patrn que soluciona de forma simple y efectiva los problemas de construccin en tal zona. [AIX77]

A modo de complemento, considero muy importante e interesante citar 2 principios postulados por Martin Fowler en Analysis Patterns [Fowler97] y que debemos tener en mente en todo momento al utilizar patrones:

y y

Los patrones son un punto de partida, no un destino. Los modelos no estn bien o mal, sino que son ms o menos tiles.

Como reflexin final de esta seccin, podemos aadir que un patrn de diseo no es una solucin en s misma, sino la documentacin de la forma en que construyeron soluciones a problemas similares en el pasado, lo cual permite una mejor gestin de la experiencia y transferencia de conocimientos. Patrones de software Si bien la teora original de los patrones aplica a la construccin de casas y planeamiento urbanstico, tambin puede ser aplicada al software. Los patrones de software facilitan la reutilizacin del diseo y de la arquitectura, capturando las estructuras estticas y dinmicas de colaboracin de soluciones exitosas a problemas que surgen al construir aplicaciones. De la misma forma que hemos buscado una definicin para el concepto general de patrones en la literatura existente, haremos lo propio con los patrones de software. Una definicin de este tipo de patrones que goza de amplia aceptacin en la comunidad del software es la dada por Richard Gabriel en A Timeles Way of Hacking [Hillside03]: style="color: #FF9900"Cada patrn es una regla de 3 partes, que expresa una relacin entre un contexto, un sistema de fuerzas que ocurren repetidamente en ese contexto y una configuracin de software que permite que se resuelvan esa fuerzas. Como podemos fcilmente observar, esta definicin es una adaptacin al mundo del software de la definicin dada por Christopher Alexander, citada en la seccin anterior. Otra definicin complementaria, ms enfocada en el mbito tcnico, es la que se da en el libro de Microsoft Enterprise Development Reference Architecture [Microsoft04]: Una descripcin de un problema recurrente que ocurre en un contexto determinado y, basada en un conjunto de fuerzas, recomienda una solucin. La solucin es usualmente un mecanismo simple: una colaboracin entre dos o ms clases, objetos, servicios, procesos, threads, componentes o nodos que trabajan juntos para resolver el problema identificado por el patrn. Finalmente, no podemos dejar de citar la frase con que comienza el libro Pattern Oriented Software Architecture,Volume 1 [Buschmann96], que incluimos a continuacin: Los patrones le ayudan a construir sobre la experiencia colectiva de ingenieros de software experimentados. Estos capturan la experiencia existente y que ha demostrado ser exitosa en el desarrollo de software, y ayudan a promover las buenas prcticas de diseo. Cada patrn aborda un problema especfico y recurrente en el diseo o implementacin de un sistema de software. Caractersticas de un buen patrn Documentar buenos patrones puede ser una tarea muy difcil. Citando a James Coplien en [Hillside03], un buen patrn:

1. 2.

3.

4. 5.

Resuelve un problema: Los patrones capturan soluciones, no principios o estrategias abstractas. Es un concepto probado: Capturan soluciones, no teoras o especulaciones. En el caso del Design Patterns, el criterio para decidir si algo era un patrn o no, era que ste deba tener al menos 3 implementaciones reales. La solucin no es obvia: Muchas tcnicas de resolucin de problemas (como los paradigmas o mtodos de diseo de software) intentan derivar soluciones desde principios bsicos. Los mejores patrones generan una solucin a un problema indirectamente (un enfoque necesario para los problemas de diseo ms difciles). Describe una relacin: Los patrones no describen mdulos sino estructuras y mecanismos. Tiene un componente humano significante: El software sirve a las personas. Los mejores patrones aplican a la esttica y a las utilidades (de hecho, no es casual que varios de los primeros lenguajes de patrones tengan que ver con temas estticos y utilidades como Hot Draw ET++ ).

Lenguajes y sistemas de patrones Un lenguaje de patrones contiene un amplio conjunto de patrones, cuyas combinaciones conforman su gramtica. Segn Alexander, un lenguaje de patrones provee la misma expresividad que un lenguaje natural, pero aplicada a la construccin. En su libro A Pattern Language [AIX77], presenta un lenguaje de 253 patrones aplicables a la arquitectura y urbanismo. Un sistema de patrones mantiene unidos a sus patrones. Describe la forma en que se conectan y cmo se complementan entre ellos. Un sistema de patrones facilita el uso eficaz de los patrones en el desarrollo de software. Por lo tanto, podemos decir que un sistema de patrones es una coleccin de patrones, junto con las guas para su implementacin, combinacin y uso prctico en el desarrollo de software. Un sistema de patrones es similar a un lenguaje de patrones, aunque este ltimo tiene fuertemente asociado el concepto de generatividad e implica que cubre todos los aspectos de importancia en un dominio particular. La combinacin de sistemas de patrones puede conformar un lenguaje de patrones, donde la gramtica se establece a partir de las combinaciones de estos patrones. Un lenguaje de patrones define una coleccin de patrones y las reglas para combinarlos en un estilo arquitectural. Los lenguajes de patrones describen frameworks de software o familias de sistemas relacionados. Niveles de patrones En Pattern Oriented Software Architecture,Volume 1 [Buschmann96], se define una taxonoma como la que se muestra en la Figura 1. Los patrones en cada grupo varan respecto a su nivel de detalle y abstraccin.:

Figura 1: Patrones segn el nivel de detalle , adaptado de POSA. Volver al texto. Es importante destacar que esta divisin no es absoluta ni totalmente comprehensiva, dado que no incluye a otros patrones de amplia aceptacin y utilizacin como los de anlisis, integracin de aplicaciones, pruebas, etc. Pattern Happy El trmino Patterns Happy aparece en el libro Refactoring to Patterns [Kerievsky04] y es un calificativo aplicable a los programadores que se refiere al uso indiscriminado de patrones, an cuando su utilizacin no agrega ningn valor a la solucin que se esta desarrollando. Un programador Pattern Happy aprende un patrn e inmediatamente encuentra un lugar para abusar de l. Para clarificar mejor este concepto, incluyo un breve prrafo de Refactoring to Patterns donde se define este calificativo de la siguiente forma: Has aprendido alguna vez algn patrn de software y quisiste usarlo en ese mismo momento, porque te gust? Mucho? Entonces eres un amante de los patrones. Los patrones no son siempre la solucin adecuada o mejor para un problema. Si bien aaden flexibilidad, tambin aaden complejidad. Es por esto que se debe ser cuidadoso al momento de seleccionar patrones. Siempre hay que recordar que los patrones son un punto de partida y que no son dogmas incuestionables. El uso indiscriminado de patrones, an en situaciones donde no aportan ningn beneficio, puede ser un antipatrn o un claro indicador de ser un Pattern Happy (esto es alguien que abusa de los patrones sin razn). Los patrones y la Gestin del Conocimiento Los patrones permiten establecer un vocabulario comn de diseo, cambiando el nivel de abstraccin a colaboraciones entre clases y permitiendo comunicar experiencia sobre dichos problemas y soluciones. Son tambin un gran mecanismo de comunicacin para transmitir la experiencia de los ingenieros y diseadores experimentados a los ms noveles, convirtindose en unas de las vas para la gestin del conocimiento. Lo que se pretende con un catlogo de patrones no es favorecer al diseador experto (que quizs no necesite en absoluto los patrones), sino ms bien ayudar al diseador inexperto a adquirir con cierta

rapidez las habilidades de aqul, como tambin comunicar al posible cliente, si es el caso, las decisiones de diseo en forma clara y autosuficiente [Cueva04]. Principio de la pgina

Patrones de Diseo
Un patrn de diseo describe una estructura recurrente de componentes que se comunican para resolver un problema general de diseo en un contexto particular. Nomina, abstrae e identifica los aspectos clave de una estructura de diseo comn, lo que los hace tiles para crear un diseo orientado a objetos reutilizable. Identifica las clases e instancias participantes, sus roles y colaboraciones y la distribucin de responsabilidades. Tiene, en general, 4 elementos esenciales (los cuales se explican en gran detalle en el libro Design Patterns [GoF95]):

y y

Nombre: Permite describir, en una o dos palabras, un problema de diseo junto con sus soluciones y consecuencias. Al dar nombres a los patrones estamos incrementando nuestro vocabulario de diseo, lo cual nos permite disear y comunicarnos con un mayor nivel de abstraccin (en lugar de hablar de clases individuales nos referimos a colaboraciones entre clases). Problema: Describe cundo aplicar el patrn. Explica el problema y su contexto. A veces incluye condiciones que deben darse para que tenga sentido la aplicacin del patrn. Solucin: Describe los elementos que constituyen el diseo, sus relaciones, responsabilidades y colaboraciones. La solucin no describe un diseo o implementacin en concreto, sino que es ms bien una plantilla que puede aplicarse en muchas situaciones diferentes. Consecuencias: son los resultados, as como ventajas e inconvenientes de aplicar el patrn.

Los patrones de diseo no son dogmas que deben ser aceptados. Qu es y qu no es un patrn de diseo, es una cuestin que depende del punto de vista de cada uno y del nivel de abstraccin en que se trabaje. La obra con mayor aceptacin en esta campo (y podra decirse que en los patrones en general) es el libro Design Patterns: Elements of Reusable Object Oriented Software [GoF95]. En este libro se presenta un catlogo de 23 patrones que analizaremos en mayor detalle ms adelante. Esta influyente obra ha sido escrita por un grupo de 4 autores a los cuales se conoce como el Gang of Four (GoF). Por tanto, muchas veces se hace referencia a este libro como el libro del GoF. Los patrones que se presentan en el libro del GoF han sido tomados de sistemas existentes y productivos. Una de las heursticas para establecer un patrn, es que existan al menos 3 implementaciones en aplicaciones reales. Por tanto, los patrones de diseo no son abstracciones tericas, sino que estn fundados sobre una fuerte base prctica y pragmtica, producto de la experiencia. Principios de Diseo En el libro del GoF se propone unos principios fundamentales de diseo subyacentes a los patrones de diseo que permiten crear aplicaciones ms flexibles y robustas:

y y

Programar para interfaces y no para una implementacin. Favorecer la composicin de objetos frente a la herencia de clases.

Otros principios de gran importancia que se derivan de los principios anteriores son los que se detallan a continuacin:

y y

Determinar qu es comn y qu es variable (commonality analisys). y Comn = Estable Permitir el reemplazo de lo variable mediante una interfaz comn.

En este aspecto podemos trazar un paralelismo con los sistemas emergentes, dado que estos principios individuales, muy sencillos a nivel local, producen sistemas robustos y flexibles en el nivel macro. Clasificacin de patrones de diseo Como ya dijimos, en el libro del GoF se presentan 23 patrones de diseo, divididos en 3 categoras, a saber:

y y y

De Creacin: Abstraen el proceso de creacin de instancias de objetos. Ayudan a hacer a un sistema independiente de cmo se crean, se componen y se representan sus objetos. Estructurales: Tratan con la composicin de clases u objetos. Se ocupan de cmo las clases y objetos son utilizados para componer estructuras de mayor tamao. De Comportamiento: Caracterizan el modo en que las clases y objetos interactan y se reparten la responsabilidad. Ataen a los algoritmos y a la asignacin de responsabilidades entre objetos.

En la a Tabla 1 se muestra la distribucin de los 23 patrones en las categoras comentadas anteriormente:

De Creacin
Ambito Clase Factory Method

Estructurales
Adapter (de clase)

De Comportamiento
Interpreter Template Method

Objeto

Abstract Factory Builder Prototype Singleton

Adapter (de objetos) Bridge Composite Decorator Faade Flyweight Proxy

Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

Tabla 1: Clasificacin de patrones de diseo del GoF. Volver al texto . Relajacin de patrones Muchas veces los patrones son seguidos estrictamente, olvidando que son ms bien un punto de partida en lugar de una meta. Es interesante observar como incluso en el libro del GoF se relajan ciertas condiciones al momento de implementar un patrn. Para ver un ejemplo explcito de esto, se recomienda revisar la implementacin del patrn Abstract Factory en C++ en este libro (hay tambin otra en Smalltalk). Sistemas flexibles y robustos con patrones de diseo En el captulo 2 del libro del GoF, se presenta como caso de estudio la construccin de un editor de documentos, el Lexi. Luego de una primera lectura, se puede determinar que sus requisitos no funcionales incluyen la flexibilidad y la robustez (por ejemplo, el editor puede presentarse en mltiples sistemas de ventanas y cuando se crean objetos relacionados, siempre son de la misma familia). Mediante el uso de patrones de diseo (en este caso concreto, se utilizan 8 de los 23 patrones presentados en el libro) se logra una solucin que cumple con los requisitos no funcionales (y los funcionales) propuestos. Para mayor detalle sobre Lexi, ver el captulo 2 de Design Patterns [GoF95]. Los patrones de diseo no son perfectos Muchas veces se trata a los patrones de diseo como verdades universales. Esto no puede ser ms incorrecto. De hecho, los miembros del mentado GoF destacan que los patrones no son un destino sino un punto de partida. En el libro Patterns Hatching [Vlissides98] John Vlissides, uno de los miembros del GoF, analiza los patrones de diseo tradicionales desde un punto de vista diferente, intentando quitar el aura de misticismo que los rodea, detallando incluso el proceso de descubrimiento de patrones utilizado por el GoF. En esa obra el autor vuelca el contenido textual de los correos donde se discute si Multicast deba ser un patrn individual o un caso particular del Observer. Finalmente, Multicast no se public como patrn en el libro del GoF. En esa misma obra trata temas crticos y muchas veces ignorados, tales como el ciclo de vida de un Singleton (Cundo y cmo muere?), los problemas del Observer y cmo reemplazarlo en algunos casos por un Visitor y prdidas de memoria en el Visitor, entre otros. Principio de la pgina

Referencias
[Alexander79] [AIX77] [BMMM98] Alexander, Christopher: A Timeless Way of Building, Oxford University Press, 1979. Alexander, Christopher et al.: A Pattern Language, Oxford University Press, 1977. Brown, W., Malveau, R., Mc Cormick III, H., Mowbray, T.: Antipatterns: Refactoring Software, Architectures and Project in Crisis, Wiley and Sons, 1998. [Buschman96] Buschmann, Frank et al.: Pattern Oriented Software Architecture, Volume 1: A System of Patterns, Willey & Sons, 1996.

[Cueva04] [Evitts00] [Fowler03] [Fowler97] [Fowler99] [Gall75]

Cueva Lovelle, Juan Manuel: Tecnologa de Objetos: Patrones de Diseo, 2004. Evitts, Paul: A UML Pattern Language, SAMS Publishing, 2000. Fowler, Martin: Enterprise Application Architecture Patterns, Addison Wesley, 2003. Fowler, Martin: Analysis Patterns: Reusable Object Models, Adisson Wesley, 1997. Fowler, Martin: Refactoring: Improving the Design of Existing Code, Adisson Wesley, 1999. Gall, John: Systemantics: How Systems Work and Especially How They Fail, New York, Quadrangle, 1975.

[GoF95]

Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995.

[Hillside03] [Hophe03]

Hillside Group: Home of the Patterns Library, 2003 <en lnea>http://hillside.net/ . Hophe, Gregor, Woolf, Robert: Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions, Addisson Wesley, 2003.

[Kerievsky04]

Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004.

[McCormick98] McCormick, Hays: Antipatterns Tutorial, 1998 <en lnea>http://www.antipatterns.com/briefing/sld001.htm. . [Microsoft03] [Microsoft04] [PPR04] [ST01] Microsoft Corp: Enterprise Solution Patterns, Microsoft Press, 2003. Microsoft Corp: Enterprise Development Reference Architecture, Microsoft Press, 2004. C2 WikiWikiWeb: Portland Pattern Repository <en lnea>http://c2.com/ppr/ . Shalloway, Alan; Trott James: Design Patterns Explained: A New perspective on Object Oriented Design, Pearson Education, 2001. [Vlissides98] Vlissides, John: Pattern Hatching: Design Patterns Applied, Addison Wesley, 1998.

Len Welicki es Profesor Asociado de Ingeniera Web en el Mster en Ingeniera del Software de la Universidad Pontificia de Salamanca, Madrid, Espaa; donde actualmente est realizando el Doctorado en Ingeniera Informtica, su tesis doctoral trata sobre las Arquitecturas de Software y Paradigmas No Convencionales para Ingeniera Web. Trabaja como Arquitecto de Software. Cuenta con ms de 12 aos de experiencia profesional en diversas reas de la Ingeniera del Software.

Patrones y Antipatrones: una Introduccin - Parte II

Por Len Welicki Artculos relacionados Patrones y Antipatrones: una Introduccin - Parte I

Contenido
Patrones de arquitectura Categoras de los patrones de arquitectura Categoras de POSA Categoras de PEAA Ejemplo: El patrn Modelo-Vista-Controlador Patrones de diseo en el MVC Antipatrones Por qu estudiar antipatrones Categoras de antipatrones Otros tipos de patrones... Patrones en todas partes! Referencias

Patrones de arquitectura
Los patrones de arquitectura expresan el esquema fundamental de organizacin para sistemas de software. Proveen un conjunto de subsistemas predefinidos; especifican sus responsabilidades e incluyen reglas y guas para organizar las relaciones entre ellos. Los patrones de arquitectura representan el nivel ms alto en el sistema de patrones propuesto en Pattern Oriented Software Architecture - Volume 1, reflejado en la la Figura 1 de la Parte I de este artculo. Ayudan a especificar la estructura fundamental de una aplicacin. Cada actividad de desarrollo es gobernada por esta estructura; por ejemplo, el diseo detallado de los subsistemas, la comunicacin y colaboracin entre diferentes partes del sistema, etc. Cada patrn de arquitectura ayuda a conseguir una propiedad especfica en el sistema global; por ejemplo, la adaptabilidad de la interfaz de usuario. Los patrones que dan soporte a caractersticas similares se agrupan en una misma categora. Categoras de los patrones de arquitectura A continuacin analizaremos la categorizacin utilizada en 2 de los sistemas de patrones de arquitectura ms extendidos y celebrados: el de Pattern Oriented Software Architecure - Volume 1[Buschmann96] (en adelante, POSA) y el de Pattern of Enterprise Application Architecture [Fowler03] (en adelante, PEAA).

Categoras de POSA
En POSA, libro de referencia de patrones de arquitectura, se divide a los patrones en las siguientes categoras:

y y y

From Mud to Structure: los patrones en esta categora ayudan a evitar un mar de componentes u objetos. En particular, soportan una descomposicin controlada de una tarea del sistema en subtareas que cooperan. Distributed Systems Interactive Systems Adaptable Systems

La Tabla 2 muestra la distribucin de los patrones de POSA en las categoras enunciadas anteriormente:

From Mud to Structure

Layers Pipes and Filtres Blackboard

Distributed Systems
Broker

Interactive Systems
Model-View-Controller Presentation-AbstractionControl

Adaptable Systems
Microkernel Reflection

Tabla 2: Clasificacin de patrones de arquitectura de POSA. Volver al texto .

Categoras de PEAA
En PEAA, Martin Fowler describe una gran cantidad de patrones orientados a la arquitectura de aplicaciones empresariales. La visin de Fowler es ms pragmtica y est alineada a la definicin de arquitectura que establece en el Captulo 1 de esa obra: ...1) deconstruccin de ms alto nivel de un sistema en sus partes componentes; 2) aquellas cosas que resulta difcil cambiar... En PEAA se definen las siguientes categoras de patrones:

y y y

y y y

Layering: Patrones para dividir un sistema en capas. Organizacin de la lgica del dominio: Formas de organizar los objetos del dominio. Mapping to Relational Databases: Se relaciona con la comunicacin entre la lgica del dominio y los repositorios de datos. Incluye el mapeo entre modelos de objetos y bases de datos relacionales. En la actualidad, se consume mucho tiempo de desarrollo en la realizacin de estas tareas debido a las diferencias de impedancia entre SQL y los lenguajes orientados a objetos tales como C#, C++, Java, etc. Presentacin Web: La presentacin Web es uno de los desafos que han tenido que sortear en los ltimos aos las aplicaciones empresariales. Los clientes delgados Web proveen muchas ventajas, siendo una de las principales la facilidad de distribucin (no es necesario instalar software en los equipos cliente). Esta categora incluye una serie de patrones para gestionar la presentacin Web. Concurrencia: Manejo de la concurrencia. Las aplicaciones actuales basadas en tecnologas Web tienen grandes necesidades de gestin de la concurrencia. Estado de sesin: Patrones para el manejo de la sesin en servidores Web. Estrategias de Distribucin: Distribucin de objetos en mltiples emplazamientos, basada en conocimientos empricos en clientes.

En la tabla a continuacin se muestra la distribucin de los patrones definidos en Patterns of Enterprise Application Architecture en las categoras mencionadas arriba: La tabla Tabla 3 muestra la distribucin de los patrones definidos en Patterns of Enterprise Application Architecture en las categoras mencionadas anteriormente:

Domain Logic Pattern

Transaction Script Domain Model Table Module Service Layer

Mapping toRelational Databases

Data Source Architectural Patterns Table Data Gateway Row Data Gateway Active Record Data Mapper Object Relational Behavioral Patterns Unit of Work Identity Map Lazy Load Object Relational Structural Patterns Identity Field Foreign Key Mapping Association Table Mapping Dependent Mapping Embedded

Web Presentation Patterns

Model View Controller Page Controller Front Controller Template View Transform View Two Step View Application Controller

Distribution Offline Patterns Concurrency Patterns

Remote Faade Optimistic Offline Lock

Session State Patterns

Client Session State Server Session State Database Session State

Base Patterns
Gateway Mapper Layer Supertype Separated Interface Registry Value Object Money Special Case Plugin Service Stub Record Set

Data Transfer Pesimistic Object Offline Lock CoarseGrained Lock Implicit Lock

Value Serialized LOB Single Table Inheritance Class Table Inheritance Table Inheritance Concrete Inheritance Inheritance Mappers ObjectRelational Metadata Mapping Patterns Metadata Mapping Query Object Repository

Tabla 3: Clasificacin de patrones de arquitectura de aplicaciones empresariales de PEEA. Volver al texto . Un detalle interesante para destacar de este libro es que se provee cdigo fuente en Java y/o C# de todos los patrones. Ejemplo: El patrn Modelo-Vista-Controlador El Model-View-Controller (Modelo-Vista-Controlador, en adelante MVC) fue introducido inicialmente en la comunidad de desarrolladores de Smalltalk-80. MVC divide una aplicacin interactiva en 3 reas: procesamiento, salida y entrada. Para esto, utiliza las siguientes abstracciones:

y y y

Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representacin de salida y/o comportamiento de entrada. Vista (View): Muestra la informacin al usuario. Obtiene los datos del modelo. Pueden existir mltiples vistas del modelo. Cada vista tiene asociado un componente controlador. Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsacin de botones del ratn, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio (service requests en el texto original) para el modelo o la vista. El usuario interacta con el sistema a travs de los controladores.

Las Vistas y los Controladores conforman la interfaz de usuario. Un mecanismo de propagacin de cambios asegura la consistencia entre la interfaz y el modelo. La separacin del modelo de los componentes vista y del controlador permite tener mltiples vistas del mismo modelo. Si el usuario cambia el modelo a travs del controlador de una vista, todas las otras vistas dependientes deben reflejar los cambios. Por lo tanto, el modelo notifica a todas las vistas siempre que sus datos cambien. Las vistas, en cambio, recuperan los nuevos datos del modelo y actualizan la informacin que muestran al usuario. La Figura 2 muestra la estructura del patrn MVC:

Figura 2: Diagrama de clases de MVC, tomado de [Buschman96].Volver al texto . Este patrn es muy popular y ha sido portado a una gran cantidad de entornos y frameworks como entre los que se encuentran WinForms, ASP .Net, etc. Las herramientas de programacin visual como Visual Basic, Visual Studio .Net, etc., siguen tambin alguna variante de este esquema. El MVC es un patrn ampliamente utilizado en mltiples plataformas y lenguajes. Algunos de sus principales beneficios son:

y y

Menor acoplamiento y Desacopla las vistas de los modelos y Desacopla los modelos de la forma en que se muestran e ingresan los datos Mayor cohesin y Cada elemento del patrn esta altamente especializado en su tarea (la vista en mostrar datos al usuario, el controlador en las entradas y el modelo en su objetivo de negocio) Las vistas proveen mayor flexibilidad y agilidad y Se puede crear mltiples vistas de un modelo y Se puede crear, aadir, modificar y eliminar nuevas vistas dinmicamente y Las vistas pueden anidarse y Se puede cambiar el modo en que una vista responde al usuario sin cambiar su representacin visual y Se puede sincronizar las vistas y Las vistas pueden concentrarse en diferentes aspectos del modelo Mayor facilidad para el desarrollo de clientes ricos en mltiples dispositivos y canales y Una vista para cada dispositivo que puede varias segn sus capacidades y Una vista para la Web y otra para aplicaciones de escritorio Ms claridad de diseo Facilita el mantenimiento

Mayor escalabilidad

Patrones de diseo en el MVC

Un patrn de arquitectura puede contener varios patrones de diseo. A modo de ejemplo, citaremos el caso del patrn de arquitectura Model-View-Controller (analizado en el apartado anterior) que contiene (o puede contener) los siguientes patrones de diseo:

y y y

y y y

Observer: Para el mecanismo de publicacin y suscripcin que permite la notificacin de los cambios en el modelo a las vistas. Composite: para la creacin de vistas compuestas. Utilizando este patrn podemos crear una jerarqua de vistas y tratar a cada vista compuesta igual que una a una vista normal. Strategy: En la relacin entre las vistas y los controladores. Utilizando este patrn podemos cambiar dinmicamente o en tiempo de compilacin los algoritmos del controlador mediante los cuales responde a su entorno. Factory Method: Para especificar la clase controlador predeterminada de una vista. Decorator: Para aadir capacidades adicionales a una vista (por ejemplo, scroll). Proxy: Para distribuir la arquitectura (Modelo y Vista-Controlador) en diferentes emplazamientos.

Para obtener ms detalles sobre este caso particular de composicin de patrones, consulta el Captulo 1 del libro del GoF o de POSA. Principio de la pgina

Antipatrones
Los antipatrones son soluciones negativas que presentan ms problemas que los que solucionan. Son una extensin natural a los patrones de diseo. Comprender los antipatrones provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los antipatrones permite conocer los errores ms comunes relacionados con la industria del software. La obra de referencia en este campo es AntiPatterns: Refactoring Software,Architectures and Projects in Crisis [BMMM98], publicada en 1998. Los antipatrones se documentan con cierto cinismo, lo cual los hace bastante graciosos y fciles de recordar. Los nombres siempre aluden al problema que tratan con humor. Se documentan mediante una plantilla (como los patrones de diseo) que incluye secciones para documentar la solucin orgen (que es la causa del problema), el contexto, las fuerzas en conflicto y las soluciones correctas propuestas (para ms detalles sobre la plantilla, ver el Captulo 3 de Antipatterns). Un buen antipatrn explica por qu la solucin original parece atractiva, por qu se vuelve negativa y cmo recuperarse de los problemas que sta genera. Segn James Coplien, un antipatrn es... ...algo que se ve como una buena idea, pero que falla malamente cuando se la implementa. La Figura 3 muestra una comparacin entre patrones y antipatrones:

Figura 3: Patrones y antipatrones [McCormick98].Volver al texto . Nota cmo en los antipatrones se parte desde una solucin (que es la que genera el problema), mientras que en los patrones se parte de un problema a resolver. Por qu estudiar antipatrones Un antipatrn (antipattern, en ingls) es una forma literaria que describe una solucin comn a un problema que genera decididamente consecuencias negativas. Segn el libro AntiPatterns: Refactoring Software,Architectures and Projects in Crisis, los antipatrones...:

y y y y

Son un mtodo eficiente para vincular una situacin general a una clase de solucin especfica. Proveen experiencia del mundo real para reconocer problemas recurrentes en la industria del software, ofreciendo tambin una solucin para sus implicaciones ms comunes. Establecen un vocabulario comn para identificar problemas y discutir soluciones. Soportan la resolucin holstica de conflictos, utilizando recursos organizacionales a diferentes niveles.

Categoras de antipatrones En el libro de antipatrones, stos se dividen en 3 grandes categoras a las cuales se denominan puntos de vista:

y y y

Desarrollo de Software: Se centran en problemas asociados al desarrollo de software a nivel de aplicacin. Arquitectura de Software: Se centran en la estructura de las aplicaciones y componentes a nivel de sistema y empresa. Gestin de Proyectos de Software: En la ingeniera del software, ms de la mitad del trabajo consiste en comunicacin entre personas y resolver problemas relacionados con stas. Los

antipatrones de gestin de proyectos de software identifican algunos de los escenarios clave donde estos temas son destructivos para el proceso de software. La Tabla 4 muestra la distribucin de los antipatrones definidos en el libro en las categoras mencionadas anteriormente:

Desarrollo de software
y y y y y y y
The Blob Lava Flow Functional Decomposition Poltergeists Golden Hammer Spaghetti Code Cut and Paste Programming

Arquitectura
y y y y y
Stovepipe Enterprise Vendor Lock-in Architecture by Implication Design by Committee Reinvent the Wheel

Gestin
y y y y y
Analysis Paralysis Death by Planning Corncob Irrational Management Project Missmanagement

Mini antipatterns Mini antipatterns Autogenerated Stovepipe Jumble Cover your Assets Wolf Ticket Warm Bodies Swiss Army Knife The Grand Old Duke of York

y
Mini antipatterns Continuous Obsolescence Ambiguous Viewpoint Boat Anchor Dead End Input Kludge Walking through a Minefield

y y

y y y y y y y y y

Blowhard Jamboree Viewgraph Engineering Fear of Success Intellectual Violence Smoke and Mirrors Throw it over the wall Fire Drill The Feud E-Mail is Dangerous

y y y y y y

y y y y

Mushroom Management

Tabla 4: Clasificacin de antipatrones. Volver al texto . En este mismo libro se plantea un modelo de referencia terico que va ms all de estas divisiones. Para ms detalles sobre el modelo, consulta los Captulos 2, 3 y 4 de esta obra. Principio de la pgina

Otros tipos de patrones...

Los patrones pueden encontrarse en todas las reas de la ingeniera informtica. A continuacin, enumeraremos una serie de reas donde existen patrones aceptados y conocidos en la industria:

y y

Idiomas: Son especficos del lenguaje de programacin. Describen cmo implementar ciertos aspectos de un problema utilizando las caractersticas de un lenguaje de programacin. Patrones de Anlisis: Los patrones enumerados en el libro Analysis Patterns: Reusable Object Models [Fowler97] provienen de diversos dominios, incluyendo las reas de la salud, servicios financieros y contabilidad. Cada uno de los patrones se describen en forma textual y con una simple notacin pre-UML. Patrones de Integracin de Aplicaciones: Patrones para integracin de aplicaciones. La obra ms popular al respecto es Enterprise Integration Patterns [Hophe03], de Gregor Hophe y Bobby Woolf. Patrones de UI: Patrones referentes a interfaces de usuarios. Existen distintas categoras bien diferenciadas: algunas se encargan de detalles relacionados con la cognicin, memoria a corto plazo y mejoras en la experiencia del usuario, mientras que otros describen tcnicas de ingeniera para crear interfaces de usuario. Patrones de Pruebas: Patrones para disear y realizar pruebas.

Principio de la pgina

Patrones en todas partes!

Al momento de escribir este trabajo, una bsqueda de la palabra pattern en los principales buscadores retorna ms de 20.000.000 resultados. Evidentemente no todos los resultados se refieren a patrones de software, pero en la primera pgina de resultados aparecen sitios emblemticos sobre patrones de software como Hillside, Portland Pattern Repository y PatternLanguage.com. Actualmente, hay disponible una amplia literatura sobre patrones. De hecho, las principales casas de software tienen sus publicaciones sobre patrones que pueden implantarse directamente sobre sus tecnologas. Principio de la pgina

Referencias
[Alexander79] [AIX77] [BMMM98] Alexander, Christopher: A Timeless Way of Building, Oxford University Press, 1979. Alexander, Christopher et al.: A Pattern Language, Oxford University Press, 1977. Brown, W., Malveau, R., Mc Cormick III, H., Mowbray, T.: Antipatterns: Refactoring Software,Architectures and Project in Crisis, Wiley and Sons, 1998. [Buschman96] Buschmann, Frank et al.: Pattern Oriented Software Architecture, Volume 1: A System of Patterns, Willey & Sons, 1996. [Cueva04] [Evitts00] [Fowler03] [Fowler97] Cueva Lovelle, Juan Manuel: Tecnologa de Objetos: Patrones de Diseo, 2004. Evitts, Paul: A UML Pattern Language, SAMS Publishing, 2000. Fowler, Martin: Enterprise Application Architecture Patterns, Addison Wesley, 2003. Fowler, Martin: Analysis Patterns: Reusable Object Models, Adisson Wesley, 1997.

[Fowler99] [Gall75]

Fowler, Martin: Refactoring: Improving the Design of Existing Code, Adisson Wesley, 1999. Gall, John: Systemantics: How Systems Work and Especially How They Fail, New York, Quadrangle, 1975.

[GoF95]

Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995.

[Hillside03] [Hophe03]

Hillside Group: Home of the Patterns Library, 2003 <en lnea>http://hillside.net/. Hophe, Gregor, Woolf, Robert: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addisson Wesley, 2003.

[Kerievsky04]

Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004.

[McCormick98] McCormick, Hays: Antipatterns Tutorial, 1998 <en lnea>http://www.antipatterns.com/briefing/sld001.htm. [Microsoft03] [Microsoft04] [PPR04] [ST01] Microsoft Corp: Enterprise Solution Patterns, Microsoft Press, 2003. Microsoft Corp: Enterprise Development Reference Architecture, Microsoft Press, 2004. C2 WikiWikiWeb: Portland Pattern Repository <en lnea>http://c2.com/ppr/. Shalloway, Alan; Trott James: Design Patterns Explained: A New perspective on Object Oriented Design, Pearson Education, 2001. [Vlissides98] Vlissides, John: Pattern Hatching: Design Patterns Applied, Addison Wesley, 1998.

Len Welicki es Profesor Asociado de Ingeniera Web en el Mster en Ingeniera del Software de la Universidad Pontificia de Salamanca, Madrid, Espaa; donde actualmente est realizando el Doctorado en Ingeniera Informtica, su tesis doctoral trata sobre las Arquitecturas de Software y Paradigmas No Convencionales para Ingeniera Web. Trabaja como Arquitecto de Software. Cuenta con ms de 12 aos de experiencia profesional en diversas reas de la Ingeniera del Software.

Patrones de Fabricacin: Fbricas de Objetos

Por Len Welicki

Contenido
1. Introduccin 1.1. Fbricas 1.2. Factory Method vs. Creation Methods 1.3. Relacin entre los Patrones de Factora 2. Factory Method 2.1. Definicin del Patrn 2.2. Breve Discusin 2.3. Ejemplo "No Software" 2.4. Ejemplos en .net Framework 2.5. Ejemplos de Cdigo 2.5.1. Variaciones de Factory Method 2.5.1.1. Creador es una Clase Abstracta o Interface 2.5.1.2. Creador es una Clase Concreta con Implementacin Predeterminada 2.5.1.3. Mtodos de Fabricacin Parametrizados 2.5.1.4. Lazy Initialization 2.5.1.5. Combinacin de Factory Method y Template Method 3. Abstract Factory 3.1. Definicin del Patrn 3.2. Breve Discusin 3.3. Factory Method y Abstract Factory 3.4. Ejemplo "No Software" 3.5. Ejemplos en .net 3.6. Ejemplo de Cdigo 4. Factory Pattern (Simple Factory) 4.1. Ejemplos de Cdigo 4.2. Por qu estas Clases no se engloban en los Patrones Anteriores? 4.2.1. Simple Factory y Factory Method 4.2.2. Simple Factory y Abstract Factory 5. Conclusin: Flexibilidad y Complejidad Referencias y Bibliografa

1. Introduccin
En este artculo analizaremos los patrones de fabricacin ms conocidos. Llamamos patrones de fabricacin a aquellos patrones que involucran algn tipo de factora o fbrica (factory, en ingls) de objetos. Estos patrones entran en la categora de patrones de creacin [GoF95], la cual comparten con otros patrones tales como el Singleton, Builder y Prototype [GoF95]. Los objetos de fabricacin (fbricas) tienen la responsabilidad de crear instancias de objetos de otras clases. Tienen adems la responsabilidad y el conocimiento necesario para encapsular la forma en que se crean determinados tipos de objetos en una aplicacin.

Existen diferentes patrones de fabricacin. En este artculo, trataremos Abstract Factory, Factory Method, y Simple Factory. Los dos primeros estn incluidos en el catlogo del GoF (presentado y analizado en la entrega anterior) y sern tratados en mayor profundidad. 1.1. Fbricas Para comenzar con nuestro estudio debemos definir claramente qu es una factora o fbrica. De la misma forma que sucede con muchos conceptos en la Ingeniera del Software, existen varias definiciones para este trmino (en la entrega anterior hemos experimentado esta situacin para el concepto de patrn); por tanto, es fundamental clarificar este concepto para sentar las bases de nuestro estudio posterior. El trmino factory (o fbrica) adolece de ser sobreutilizado e impreciso. Mucha gente se refiere a factory para indicar una implementacin de Factory Method o de Abstract Factory (patrones definidos en el libro del GoF). Otros sin embargo, se refieren a un objeto que crea instancias de otros, aunque no sigue las reglas de los patrones mencionados anteriormente. La falta de consenso sobre el trmino dificulta la comunicacin que, como ya hemos visto anteriormente, es uno de los objetivos de los patrones (poder referirse en forma unvoca a una abstraccin de mayor nivel que la clase individual, incrementando as el vocabulario de los ingenieros de software). Recordemos entonces una importante frase de la entrega anterior: Los Patrones permiten establecer un vocabulario comn de diseo, cambiando el nivel de abstraccin a colaboraciones entre clases y permitiendo comunicar experiencia sobre dichos problemas y soluciones. Son tambin un gran mecanismo de comunicacin para transmitir la experiencia de los ingenieros y diseadores experimentados a los ms nveles, convirtindose en unas de las vas para la gestin del conocimiento. Por tanto, es muy importante establecer un significado claro para este trmino, a los efectos de construir este vocabulario comn. Llamaremos fbrica, factora o factory a una clase que implemente uno o ms mtodos de creacin, que son los mtodos que se encargan de crear instancias de objetos (estas instancias pueden ser de esta misma clase o de otras). Esta clase tiene entre sus responsabilidades la creacin de instancias de objetos, pero puede tener tambin otras responsabilidades adicionales. Los mtodos de creacin pueden ser estticos. Existen diferentes "tipos" de fbricas. A continuacin enumeraremos cada una de ellos, a los efectos de dejar bien en claro sus significados: Simple Factory Clase utilizada para crear nuevas instancias de objetos. Factory Method Define una interfaz para crear objetos pero deja que sean las subclases las que deciden qu clases instanciar. Abstract Factory

Proporciona una interfaz para crear familias de objetos relacionados o que dependen entre s, sin especificar sus clases concretas. En la Figura 1 se muestra los diferentes tipos de factoras con las que trabajaremos en este artculo. En cada caso, cada cuadro representa una clase y cada lnea es un mtodo en esa clase:

Figura 1: Tipos de fbricas, inspirado en [Kerievsky04]. Volver al texto. A lo largo de este artculo estudiaremos en mayor profundidad cada uno de estos patrones. 1.2 Factory Method vs. Creation Methods Cmo llamar a un mtodo que crea instancias de otras clases? Muchas veces se lo llama Factory Method, aunque esto puede prestarse a malos entendidos, dado que puede confundirse con el patrn del GoF homnimo. Por lo tanto, llamaremos a los mtodos (o funciones) encargadas de crear instancias de otras clases Creation Methods (mtodos de creacin) a los efectos de establecer claramente esta diferenciacin. En la Figura 2 se muestra la relacin entre los conceptos Factory Method y Creation Method:

Figura 2: Relacin entre Factory Method y Factory Function; Factory Method contiene varios Creation Methods (mtodos de creacin). Volver al texto. 1.3 Relacin entre los Patrones de Factora Los patrones no existen aislados el uno del otro, sino ms bien dentro del contexto de un lenguaje o sistema de patrones. Por consiguiente existen relaciones entre ellos que pueden determinar cundo, cmo y por qu utilizar uno u otro. Los patrones de fabricacin no estn exentos de esto. En el libro del GoF por ejemplo, se indica que el patrn Abstract Factory se implementa utilizando Factory Method. A su vez, ambos patrones estn relacionados con otros patrones del catlogo. En la Figura 3 se muestran las relaciones entre patrones de creacin que existen dentro del catlogo del GoF [GoF95]:

Figura 3: Relaciones entre los patrones de creacin del catlogo del GoF (tomada de [GoF95]). Hemos marcado con un borde rojo los patrones que tratamos en este artculo (Abstract Factory y Factory Method). Volver al texto. En la Figura 4 se representa la forma en que estn relacionados todos los conceptos referentes a las fbricas estudiados hasta ahora:

Figura 4: Diagrama basado en UML que muestra las relaciones entre los distintos patrones tratados en este artculo. Volver al texto. En la vida real, los patrones no estn segregados por lneas absolutas. A menudo, una clase puede utilizar uno o ms patrones, haciendo difuso el lmite entre ambos. Adicionalmente, se puede comenzar utilizando un patrn sencillo y evolucionar hacia otro ms complejo en funcin de las necesidades de nuestra aplicacin Principio de la pgina

2. Factory Method
Factory Method define una interfaz para crear objetos, pero deja que sean las subclases quienes decidan qu clases instanciar; permite que una clase delegue en sus subclases la creacin de objetos. 2.1 Definicin del Patrn A continuacin presentaremos una versin reducida de la plantilla de este patrn. Para obtener la versin completa, consulta el libro del GoF: Problema Una clase necesita instanciar otra clase derivada de una tercera clase, pero no sabe cul. Factory Method permite a la clase derivada tomar esta decisin. Solucin Una clase derivada toma la decisin sobre qu clase instanciar y cmo instanciarla (Ver Figura 5):

Figura 5: Diagrama OMT de Factory Method, tomado del libro del GoF. Volver al texto. Participantes Producto Define la interfaz de los objetos que crea el mtodo de fabricacin. ProductoConcreto Implementa la interfaz Producto. Creador Declara el mtodo de fabricacin, el cual devuelve un objeto del tipo Producto. Tambin puede definir una implementacin predeterminada del mtodo de fabricacin que devuelve un objeto ProductoConcreto. Puede llamar al mtodo de fabricacin para crear un objeto Producto. CreadorConcreto Redefine el mtodo de fabricacin para devolver una instancia de ProductoConcreto. Aplicabilidad Usar cuando: Una clase no puede prever la clase de objetos que debe crear. Una clase quiere que sean sus subclases quienes especifiquen los objetos que sta crea. Las clases delegan la responsabilidad en una de entre varias clases auxiliares, y queremos localizar concretamente en qu subclase de auxiliar se delega.

y y y

Consecuencias Proporciona enganches para las subclases. Crear objetos dentro de una clase con un mtodo de fabricacin es siempre ms flexible que hacerlo directamente. Conecta jerarquas de clases paralelas.

Resumen 1: Vista simplificada y resumida del patrn Factory Method, tomado de [GoF95] y [DPE01] 2.2 Breve Discusin El patrn Factory Method permite escribir aplicaciones que son ms flexibles respecto de los tipos a utilizar difiriendo la creacin de las instancias en el sistema a subclases que pueden ser extendidas a medida que evoluciona el sistema. Permite tambin encapsular el conocimiento referente a la creacin de objetos. Factory Method hace tambin que el diseo sea ms adaptable a cambio de slo un poco ms de complejidad. Se utiliza frecuentemente con Template Method. En la seccin de ejemplos de cdigo de este patrn presentaremos una implementacin de este caso. Uno de los principales inconvenientes que puede presentar este patrn es que puede requerir crear una nueva clase simplemente para cambiar la clase de Producto. 2.3 Ejemplo "No Software" En [Duell97] se presenta el siguiente ejemplo: Las prensas de moldeado a inyeccin sirven para explicar este patrn. Los fabricantes de juguetes de plstico procesan plstico en polvo para moldeado, e inyectan el plstico en moldes con las formas deseadas. La clase de un juguete (auto, figura, etc.) es determinada por el molde. En la Figura 6 se muestra un diagrama UML de este ejemplo:

Figura 6: Ejemplo del mundo real del patrn Factory Method, tomado de [Duell97]. Volver al texto. 2.4 Ejemplos en .net Framework

En .net podemos encontrar varias implementaciones de este patrn. A modo de ejemplo, hemos tomado una de ASP .net 1.1, concretamente, la implementacin del gestor de manejadores (handlers). En la Figura 7 se muestra el diagrama del GoF actualizado con objetos del Framework .net; en este caso los del ejemplo seleccionado:

Figura 7: Ejemplo de implementacin del patrn Factory Method en ASP .net. Volver al texto. 2.5 Ejemplos de Cdigo Existe un nmero de variantes para este patrn. En esta seccin enumeraremos y explicaremos las principales y ofreceremos ejemplos en C# para cada caso. Para los ejemplos, utilizaremos como clases Producto un modelo de objetos muy sencillo de una tienda de mascotas. En este caso, Mascota hace las veces del participante Producto; y Perro, Gato y Vbora son instancias de Producto Concreto (Ver Figura 8):

Figura 8: Modelo de objetos Producto utilizados en los ejemplos de implementacin del patrn Factory Method.Volver al texto.

2.5.1 Variaciones de Factory Method

Si bien existen diversas variaciones en la implementacin de este patrn, los dos principales casos son los que se indican a continuacin:

y y

Creador es abstracto y no provee una implementacin para el mtodo de creacin que declara. Creador es una clase concreta y provee una implementacin predeterminada para el mtodo de creacin que declara.

En las siguientes secciones presentaremos las distintas opciones de implementacin de este patrn y para cada una de ellas ofreceremos un ejemplo en C#.

2.5.1.1 Creador es una Clase Abstracta o Interfaz

En este caso, el creador es una clase abstracta o interfaz (siempre que sea posible, es ms recomendable utilizar una interfaz) y no provee una implementacin predeterminada. Por lo tanto, son las clases derivadas las que tienen la responsabilidad sobre la implementacin de la funcin de creacin. En el ejemplo que se muestra a continuacin existe un creador que crea instancias de Perro y otro que crea instancias de Gato, ambos basados en la misma interfaz:

/// <summary> /// Creador sin implementacin. Puede ser una interfase /// o una clase abstracta, donde los mtodos de creacin /// no tienen implementacin /// </summary> public interfase ICreador { /// <summary> /// Mtodo de creacin /// </summary> /// <returns>Instancia de una mascota</returns> Mascota Crear(); } /// <summary> /// Creador Concreto. Implementa la interfase de creacin /// </summary> public class CreadorConcreto: ICreador { /// <summary> /// Mtodo de creacin /// </summary> /// <returns>Instancia de una mascota</returns> public Mascota Crear() { return new Perro(); } } /// <summary> /// Otra instancia de Creador Concreto. /// Implementa la interfase de creacin /// </summary> public class OtroCreadorConcreto: ICreador { /// <summary> /// Mtodo de creacin. En este caso, retorna /// un una instancia de una mascota de la clase Gato

/// </summary> /// <returns>Instancia de una mascota</returns> public Mascota Crear() { return new Gato(); } }

Cdigo 1 - Ejemplo de Factory Method donde el Creador es una interfaz. En este ejemplo de cdigo, existen 2 creadores concretos que son las clases que implementan la interfase ICreador. Cada creador crea un subtipo diferente de Mascota, por ejemplo, Perro en el primer caso y Gato en el segundo.

2.5.1.2 Creador es una Clase Concreta con Implementacin Predeterminada

En este caso, la clase base provee una implementacin predeterminada de la funcin de creacin. Por lo tanto, las clases hijas pueden re-implementarla o utilizar la implementacin provista por la clase base. Para lograr este comportamiento, la funcin de creacin en la clase base debe marcarse como virtual (esto significa que puede ser redefinida por las clases derivadas). En el ejemplo a continuacin veremos como la clase base crea instancias de objetos de tipo Perro y la subclase, en cambio, crea instancias de Gato (redefiniendo la implementacin del mtodo de creacin del tipo base):

/// <summary> /// Creador. Esta es la clase base del Factory Method. /// Provee una implementacin default del mtodo de creacin, /// que puede ser redefinida por los mtodos hijos /// </summary> public class Creador { /// <summary> /// Metodo de creacin /// </summary> /// <returns>Instancia de una mascota</returns> public virtual Mascota Crear() { return new Perro(); } } /// <summary> /// Creador Concreto. Redefine el mtodo de creacin /// definido en Creador, cambiando el "ProductoConcreto" /// que se retorna /// </summary> public class CreadorConcreto: Creador { /// <summary> /// Metodo de creacin /// </summary> /// <returns>Instancia de una mascota</returns> public override Mascota Crear()

{ return new Gato(); } }

Cdigo 2 - Ejemplo de Factory Method donde Creador es una clase concreta y tiene implementacin predeterminada. Creador provee una implementacin predeterminada que es redefinida por los creadores concretos. En el ejemplo, CreadorConcreto redefine el mtodo Crear, retornando una instancia de otra subclase de Mascota (concretamente Gato en lugar de Perro).

2.5.1.3 Mtodos de Fabricacin Parametrizados

Otra variacin del patrn permite que la funcin de creacin cree mltiples instancias de Producto. La funcin recibe como entrada un parmetro que identifica el tipo de objeto a crear. Todos los objetos creados por esta funcin deben ser subclases de Producto. En el ejemplo que se muestra a continuacin, se crea una mascota en funcin de un parmetro con el nombre del tipo de Mascota. En este mismo ejemplo se crea una subclase de Creador (un creador concreto) muy quisquilloso: slo puede crear instancias de mascotas de tipo Perro. En los dems casos dispara una excepcin, explicando el motivo por el cual no ha podido crear la instancia:

/// <summary> /// Creador. Esta es la clase base del Factory Method. /// Provee una implementacin default del mtodo de creacin, /// que puede ser redefinida por los mtodos hijos. El mtodo /// de creacin acepta parmetros, permitiendo crear diferentes /// instancias de mascotas /// </summary> public class Creador { /// <summary> /// Funcin de creacin de ordenadores. Recibe el tipo /// de ordenador a crear y retorna una instancia valida /// </summary> /// <remarks> /// Dado que la funcin es virtual, puede ser modificada /// sus las clases hijas /// </remarks> /// <param name="tipo">Tipo de ordenador (producto) a crear</param> /// <returns>Instancia valida de ordenador (producto)</returns> public virtual Mascota Crear(string tipo) { switch (tipo.ToLower()) { case "perro": return new Perro(); case "gato": return new Gato(); case "vibora": return new Vibora(); default: throw new ArgumentException("Tipo de mascota desconocido"); }

} } /// <summary> /// Creador Concreto. Redefine el mtodo de creacin definido en Creador, /// cambiando el "ProductoConcreto" que se retorna. En este caso, /// slo permite crear mascotas del tipo "Perro". En los dems casos, /// dispara una excepcin /// </summary> public class CreadorConcreto: CreadorParametrizado { /// <summary> /// Funcin de creacin de ordenadores. Solo permite /// crear Mascotas de tipo Perro. /// </summary> /// <remarks> /// Esta funcin redefine a la funcin anterior, cambiando /// el comportamiento de creacin en funcin del mtodo /// </remarks> /// <param name="tipo">Tipo de ordenador (producto) a crear</param> /// <returns>Instancia valida de ordenador (producto)</returns> public override Mascota Crear(string tipo) { switch (tipo.ToLower()) { case "perro": return new Perro(); case "gato": throw new ArgumentException("Soy alrgico a los gatos."); case "vbora": throw new ArgumentException("No se puede tener una vbora como mascota."); default: throw new ArgumentException("Tipo de mascota desconocido"); } } }

Cdigo 3 - Ejemplo de Factory Method con el mtodo de creacin parametrizado. Nota que el mtodo de creacin adems de recibir un parmetro est marcado como virtual, para poder ser redefinido en las clases hijas.

2.5.1.4 Lazy Initialization

En algunos casos, por ejemplo cuando la creacin de la instancia tiene un coste elevado, se puede mantener una referencia a una instancia vlida, la cual slo es creada la primera vez que se solicita. Por lo tanto, slo incurrimos en el coste de creacin una nica vez. A continuacin se muestra un ejemplo de cmo implementar esta tcnica:

/// /// /// ///

<summary> Creador. Esta es la clase base del patrn Factory Method. Provee una implementacin default del mtodo de creacin, que puede ser redefinida por los mtodos hijos. El mtodo

/// de creacion utiliza Lazy Instantiation. /// </summary> public class Creador { // instancia de "Producto" private Mascota producto; /// <summary> /// Mtodo de creacin. /// </summary> /// <remarks> /// Es un "TemplateMethod". Para modificar la clase a instanciar, /// se debe modificar en las clases hijas el mtodo CrearOrdenador /// </remarks> /// <returns>Instancia de Mascota</returns> public Mascota Crear() { /// si no se ha creado el producto, lo creamos if (this.producto == null) this.CrearMascota(); /// retorna la instancia del producto return this.producto; } /// <summary> /// Mtodo real de fabricacin. /// </summary> /// <remarks> /// Este mtodo que crea la instancia. Es el que debe ser redefinido /// en las clases hijas para modificar la clase del objeto a crear /// </remarks> protected virtual void CrearMascota() { this.producto = new Perro(); } }

Cdigo 4 - Ejemplo de Factory Method utilizando Lazy Load. Otro aspecto interesante a notar es la utilizacin del patrn Template Method [GoF95] para seleccionar el tipo de la instancia a crear. La funcin CrearMascota funciona como Template Method: este mtodo tiene el comportamiento variable, mientras que crear tiene el comportamiento que no vara. Por lo tanto, si quisiramos crear una subclase para crear instancias de otro tipo de Mascota (por ejemplo Gato), slo tendramos que redefinir el mtodo CrearMascota.

2.5.1.5 Combinacin de Factory Method y Template Method

El patrn Template Method "define en una operacin el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura" [GoF95]. En el ejemplo que se muestra a continuacin mostramos cmo combinar estos dos patrones.

Para demostrar esto con un ejemplo, implementaremos un cuidador de mascotas. El cuidador tiene la responsabilidad de alimentar y pasear a nuestras mascotas. Su comportamiento puede describirse de la siguiente forma: 1. 2. 3. Obtiene una mascota para cuidar. La alimenta. Si tiene 2 ms patas, la lleva a pasear.

Las clases Cuidador y CuidadorDePerros combinan a los patrones Factory Method y Template Method. La clase Cuidador cumple los roles de Creador en Factory Method y Abstract Class en Template Method. El mtodo Cuidar tiene el comportamiento fijo y no puede ser redefinido en las clases hijas. Recordando la definicin del patrn, este mtodo contiene "la estructura del algoritmo". El mtodo abstracto CrearMascota, en cambio, es un mtodo de creacin (en Factory Method) y una operacin primitiva (en Template Method). En ambos casos este mtodo debe ser redefinido en las clases derivadas. La clase CuidadorDePerros muestra un ejemplo de cmo puede crearse un cuidador que sepa tratar con perros:

/// <summary> /// Esta es la clase que implementa Template Method /// y Factory Method. En el caso de Factory Method, /// hemos implementado la opcin donde el creador /// es una clase abstracta /// </summary> public abstract class Cuidador { /// <summary> /// Este es el template method. Este mtodo es /// el que tiene la lgica y no se redefine en /// las clases hijas /// </summary> public void Cuidar() { /// obtenemos una instancia de una mascota Mascota mascota = this.CrearMascota(); /// alimentamos a la mascota mascota.Alimentar(); /// si la mascota tiene mas de 2 patas, la llevamos a pasear if (mascota.CantidadPatas > 1) mascota.Pasear(); } /// <summary> /// Este es el mtodo de creacin (para el Factory Method) /// y la Operacin Primitiva que debe ser /// redefinida por el usuario (para el Template Method) /// </summary> /// <returns>Instancia de Mascota</returns> public abstract Mascota CrearMascota(); }

/// <summary> /// Creador Concreto. Solo redefine la operacin de creacin, pero hereda /// el comportamiento fijo de CreadorTemplateMethod /// </summary> public class CuidadorDePerro: CreadorTemplateMethod { /// <summary> /// Mtodo de creacin, redefinido de la clase base /// </summary> /// <returns>Instancia de Mascota</returns> public override Mascota CrearMascota() { return new Perro(); } }

Cdigo 5 - Ejemplo de combinacin de Factory Method y Template Method. Es importante destacar que este cdigo es un ejemplo ilustrativo y por lo tanto puede carecer de sentido en el mundo real, dado que el cuidador cuida siempre "nuevas instancias de perros". Este ejemplo podra mejorarse creando una subclase de cuidador que obtenga la instancia de Mascota a partir de una serie de criterios arbitrarios. Las tcnicas que estamos utilizando permiten probar nuevas alternativas sin afectar al cdigo existente (por ejemplo, podramos crear una subclase de cuidador, probarla y mejorarla sin necesidad de modificar a las clases CuidadorDePerros o Cuidador). Principio de la pgina

3. Abstract Factory
El patrn Abstract Factory proporciona una interfaz para crear familias de objetos relacionados o que dependen entre s, sin especificar sus clases concretas. 3.1 Definicin del Patrn Intencin Proporciona una interfaz para crear familias de objetos relacionados o que dependen entre s, sin especificar sus clases concretas. Problema Se necesita instanciar familias de objetos. Solucin Coordinar la creacin de familias de objetos. Establecer una forma para quitar las reglas de cmo realizar

la instanciacin fuera del objeto que est usando los objetos a crear. (Ver Figura 9):

Figura 9: Diagrama OMT de Factory Method, tomado del libro del GoF. Volver al texto. Participantes FabricaAbstracta Declara una interfaz para operaciones que crean objetos producto abstractos. FabricaConcreta Implementa las operaciones para crear objetos producto concretos. ProductoAbstracto Declara una interfaz para un tipo de objeto producto. ProductoConcreto Define un objeto producto para que sea creado por la fbrica correspondiente. Implementa la interfase ProductoAbstracto. Cliente Slo usa interfaces declaradas por las clases FabricaAbstracta y ProductoAbstracto.

Aplicabilidad Usar cuando: Un sistema debe ser independiente de cmo se crean, componen y representan sus productos. Un sistema debe ser configurado con una familia de productos entre varias. Una familia de objetos producto relacionados est diseada para ser usada conjuntamente y es necesario hacer cumplir esa restriccin.

y y y

Se quiere proporcionar una biblioteca de clases de productos y slo se quiere revelar sus interfaces, no sus implementaciones.

Consecuencias Asla las clases concretas. Facilita el intercambio de familias de productos. Promueve la consistencia entre productos. Desventaja: Es difcil dar cabida a nuevos tipos de productos.

y y y y

Resumen 2 - Vista simplificada y resumida del patrn Abstract Factory, tomado de [GoF95] y [DPE01]. 3.2 Breve Discusin Abstract Factory puede ser utilizado para desarrollar frameworks y sistemas que pueden ser configurados con una de mltiples familias de productos. Provee un nivel adicional de indireccin que abstrae la creacin de familias de objetos relacionados o dependientes sin especificar sus clases concretas. El objeto "fbrica" tiene la responsabilidad de proveer la funcionalidad y el protocolo para la creacin de la familia completa. Los clientes nunca deben crear objetos directamente, sino a travs de la factora. Por consiguiente, es fcil cambiar las familias de productos que se utilizan, porque el tipo especfico de cada instancia aparece slo una vez en la aplicacin: en el mtodo de creacin donde se crea la instancia. Como hemos dicho anteriormente, este patrn es utilizado cuando se desean crear familias de productos, pero... Qu queremos decir con familias de productos? Imaginemos que tenemos una aplicacin y queremos que pueda mostrarse en mltiples sistemas de ventanas como por ejemplo Windows 9x, 2000, XP, Mac OS y X-Windows. Cuando creamos los diferentes controles de usuario, es muy importante que se creen en forma consistente. Por ejemplo, en una ventana no queremos que se mezclen botones tipo Windows 95 con barras de desplazamiento de estilo MacOS. Por esto, debemos asegurarnos que todos los objetos de interfaz de usuario que creemos pertenezcan a la misma familia (Windows 95, 2000, XP MacOS, etc.). El patrn Abstract Factory nos ayuda a resolver este problema. 3.3 Factory Method y Abstract Factory

Abstract Factory generalmente se implementa utilizando Factory Method y por tanto provee al menos toda la flexibilidad de ste. La diferencia principal entre ambos es que el primero trata con familias de productos, mientras que el otro se preocupa por un nico producto. Abstract Factory se encuentra a un nivel de abstraccin mayor que Factory Method. Los diseos que usan Abstract Factory son ms flexibles que los que utilizan Factory Method, pero son tambin ms complejos. Otra diferencia notable es el mbito de ambos patrones: Factory Method es un patrn de clase, mientras que Abstract Factory es un patrn de objeto. Los patrones de clase se refieren a las relaciones entre las clases (estticas, en tiempo de compilacin) y sus subclases mientras que los de objetos tratan sobre relaciones entre instancias (dinmicas, en tiempo de ejecucin). Los patrones de objetos suelen ser preferibles a los de clases, ya que se basan en el principio fundamental de usar composicin en lugar de la herencia y en la delegacin. La mayora de los patrones del GoF tienen mbito de objeto. Para acceder a una discusin ms detallada sobre este tema, ver [GoF95]. 3.4 Ejemplo "No Software" Este patrn se encuentra en el equipamiento de cuo de metal utilizado en las fbricas de automviles japonesas. El equipamiento de cuo es un Abstract Factory que crea partes de un automvil. La misma maquinaria se utiliza para estampar la puerta derecha e izquierda, defensa delantera y trasera, etc., para diferentes modelos de autos. Mediante el uso de rodillos para cambiar los fines de estampado, las "clases concretas" producidas por la maquinaria pueden cambiarse en 3 minutos [Duell97]. En la Figura 10, que se muestra a continuacin, vemos un ejemplo de esta situacin (utilizando una notacin basada en UML):

Figura 10: Ejemplo del mundo real del patrn "Abstract Factory", tomado de . Volver al texto. 3.5 Ejemplos en .net El patrn Abstract Factory se utiliza en forma intensiva en ADO .net. En la Figura 11 se muestra cmo ha sido implementado este patrn en los objetos conexin de ADO .net:

Figura 11: Implementacin de Abstract Factory en las conexiones ADO .net. Las lneas discontinuas

representan la relacin de creacin (la notacin en este caso es OMT , la misma que se usa en el libro del GoF). Volver al texto. En la figura anterior vemos cmo mediante la utilizacin del patrn nos aseguramos que los objetos que se creen a partir de un tipo de conexin (Transaccin o Command) sean de la misma familia que la del objeto conexin (SqlClient, OracleClient, etc.) 3.6 Ejemplo de Cdigo Para mostrar el uso de este patrn, codificaremos en C# el ejemplo que se presenta en la seccin Motivacin de la plantilla de este patrn en el libro del GoF. En este caso, se busca que todos los objetos grficos que se creen en una aplicacin que soporte mltiples sistemas de visualizacin pertenezcan a la misma familia. De este manera, si creamos una ventana para ser mostrada en Windows, los controles de usuario (scrollbar, textbox, etc) que utilizaremos en ella deben ser controles para Windows. Lo mismo debera suceder si estuviramos presentando la aplicacin en un Mac. En la figura Figura 12 se muestra el diagrama OMT del ejemplo:

Figura 12: Diagrama OMT del ejemplo de Abstract Factory para regir la creacin de objetos grficos en un sistema que soporta visualizacin en mltiples sistemas de ventanas. Este diagrama ha sido tomado de la seccin Motivacin de este patrn en el libro del GoF. Volver al texto. A continuacin se muestra el cdigo C# para el diagrama anterior:

/// <summary> /// Abstract Factory. En este caso, la hemos implementado usando /// una interfase, aunque tambin puede ser una clase abstracta /// </summary> public interface IWidgetFactory { Window CreateWindow(); Scrollbar CreateScrollbar(); }

/// <summary> /// Concrete Factory (Fabrica Concreta) /// </summary> public class WindowsWidgetFactory: IWidgetFactory { public Window CreateWindow() { return new WindowsWindow(); } public Scrollbar CreateScrollbar() { return new WindowsScrollbar(); } } /// <summary> /// Concrete Factory (Fabrica Concreta) /// </summary> public class MacWidgetFactory: IWidgetFactory { public Window CreateWindow() { return new MacWindow(); } public Scrollbar CreateScrollbar() { return new MacScrollbar(); } } /// <summary> /// Producto /// </summary> public abstract class Window { public abstract void Render(); } /// <summary> /// Producto /// </summary> public abstract class Scrollbar { public abstract void Render(); } /// <summary> /// Producto Concreto (Scrollbar para Windows) /// </summary> public class WindowsScrollbar: Scrollbar { public override void Render() { Console.WriteLine("Pintando Scrollbar de Windows...");

} } /// <summary> /// Producto Concreto (Ventana para Windows) /// </summary> public class WindowsWindow: Window { public override void Render() { Console.WriteLine("Pintando Ventana de Windows..."); } } /// <summary> /// Producto Concreto (Scrollbar para Mac) /// </summary> public class MacScrollbar: Scrollbar { public override void Render() { Console.WriteLine("Pintando Scrollbar de Mac..."); } } /// <summary> /// Producto Concreto (Ventana para Mac) /// </summary> public class MacWindow: Window { public override void Render() { Console.WriteLine("Pintando Ventana de Mac..."); } } class TestClient { /// <summary> /// Punto de entrada principal de la aplicacin. /// </summary> [STAThread] static void Main(string[] args) { /// Creo los objetos para windows IWidgetFactory factory = new WindowsWidgetFactory(); Scrollbar scrollbar = factory.CreateScrollbar(); Window window = factory.CreateWindow(); window.Render(); scrollbar.Render(); /// Ahora, lo mismo pero para Mac. /// Al cambiar el tipo del factory, todos los objetos que /// se crean mediante ella son de la misma familia factory = new MacWidgetFactory(); scrollbar = factory.CreateScrollbar(); window = factory.CreateWindow();

window.Render(); scrollbar.Render(); } }

Cdigo 6 - Ejemplo de implementacin de Abstract Factory. En el ejemplo hay tambin un cliente de prueba. Principio de la pgina

4. Factory Pattern (Simple Factory)

Muchas veces, cuando la gente habla de factory pattern, se refiere a uno de los dos patrones que hemos estudiado anteriormente. Sin embargo, hay casos que no son cubiertos por estos patrones como por ejemplo, clases con mtodos estticos de fabricacin o fbricas concretas que tienen implementacin, pero sus mtodos no son redefinibles. En estos casos, estamos ante una implementacin del patrn Simple Factory. Hemos dejado este tipo de factoras para el final, dado que son ms fciles de entender y analizar que los otros patrones presentados anteriormente en este artculo. En este caso, estamos ante tipos que tienen la responsabilidad de crear instancias de objetos de otras clases, pero que no cumplen con las premisas establecidas en los patrones anteriores. 4.1 Ejemplos de Cdigo

/// <summary> /// Simple Factory /// Ejemplo con mtodo de creacin esttico /// </summary> public class CreadorDePerros { public static Mascota Create () return new Perro(); } } /// <summary> /// Ejemplo de Simple Factory /// </summary> public class CreadorDeGatos { public Mascota Create() { return new Gato(); } }

Cdigo 7 - Ejemplo de implementacin de variaciones de Simple Factory. En el primer caso, el mtodo de creacin es esttico. Nota que no pueden redefinirse los mtodos de fabricacin en ninguna de las dos clases. 4.2 Por qu estas Clases no se engloban en los Patrones Anteriores? Quizs la primer pregunta que puedes hacerte al ver el Cdigo 7 es: Por qu estas clases no se corresponden con los patrones anteriores? En este apartado intentaremos explicarlo ...

4.2.1 Simple Factory y Factory Method

Comencemos con Factory Method. Para ello es fundamental recordar la intencin de este patrn: Factory Method define una interfaz para crear objetos, pero deja que sean las subclases las que decidan qu clases instanciar. Permite que una clase delegue en sus subclases la creacin de objetos. En los ejemplos presentados en el Cdigo 7, las clases no exponen una interfaz que pueda ser redefinida por clases que deriven de sta. Por tanto, no pueden dejar que sean las subclases las que decidan qu clases instanciar ni delegar en las subclases la creacin de objetos. En ambos casos esto se debe a que el comportamiento est definido en cada clase y no puede ser redefinido en sus clases derivadas.

4.2.2 Simple Factory y Abstract Factory

Continuemos con Abstract Factory. De la misma forma que en el caso anterior, recordaremos la intencin de este patrn: Proporciona una interfaz para crear familias de objetos relacionados o que dependen entre s, sin especificar sus clases concretas. En los ejemplos presentados en el Cdigo 7, no exponen una interfaz para crear familias de objetos relacionados, dado que solo crean un nico producto y tampoco pueden ser redefinidos por las clases derivadas. Respecto a la restriccin de las familias, podras estar pensando como contra-argumento el siguiente ejemplo de cdigo:

/// <summary> /// Ejemplo de Simple Factory /// </summary> public class Creador { public static IWindow CreateWindow() { return new WindowsWindow(); } public static IScrollbar CreateScrollbar() { return new WindowsScrollbar(); } }

Cdigo 8 - Ejemplo de implementacin de creacin de familias de productos con Simple Factory.

En este nuevo ejemplo, nuestro creador s crea familias de productos, aunque tiene los siguientes inconvenientes: 1. 2. No asegura ningn tipo de consistencia. No declara una interfaz de creacin de familias de productos que pueda ser redefinida por las clases derivadas.

El punto 2 quizs sea el ms fcil de ver, aunque el punto 1 puede generar dudas ... Por eso, discutiremos brevemente el problema y lo demostraremos con un nuevo bloque de cdigo: al no tener una restriccin respecto a la interfaz de los creadores de familias, estos pueden mezclarse, produciendo inconsistencias como las que se muestran en el bloque de cdigo:

/// <summary> /// Simple Factory para Widgets de Windows /// </summary> public class WindowsCreator { public static IWindow CreateWindow() { return new WindowsWindow(); } public static IScrollbar CreateScrollbar() { return new WindowsScrollbar(); } } /// <summary> /// Simple Factory para Widgets de MAC /// </summary> public class MacCreator { public static IWindow CreateWindow() { return new MacWindow(); } public static IScrollbar CreateScrollbar() { return new MacScrollbar(); } } /// <summary> /// Ejemplo de Simple Factory /// </summary> public class ClienteDePruebaConError { public void Test() { IWindow window = CreadorWindows.CreateWindow(); IScrollbar scrollbar = CreadorMac.CreateScrollbar(); } }

Cdigo 9 - Ejemplo de inconsistencias al utilizar Simple Factory para crear familias de productos. En el ejemplo presentado en el Cdigo 9, se crean y combinan elementos de interfaz de usuario de diferentes familias. En el caso concreto de nuestro ejemplo, estamos creando una ventana de Windows y una Scrollbar de Mac. Por lo tanto, estamos violando el principio fundamental del patrn, que es proveer una interfaz consistente para la creacin de familias de productos relacionados. La forma correcta de implementar este ejemplo utilizando el patrn Abstract Factory ha sido presentada previamente en el bloque de Cdigo 6. Principio de la pgina

5. Conclusin: Flexibilidad y Complejidad

Los patrones de fabricacin estudiados a lo largo de este artculo aaden flexibilidad a las aplicaciones, pero a expensas de mayor complejidad. Por lo tanto, es recomendable analizar bien el problema a resolver antes de incluirlas. Para terminar, considero oportuno citar la siguiente frase sobre las fbricas de Robert Martin [Martin05]: No las use por defecto, y no comience utilizndolas frente al primer indicio de que puedan serle tiles ... Aguarde a tener un problema concreto que las fbricas puedan resolver. Y en ese caso, no dude en utilizarlas. Principio de la pgina

Referencias y Bibliografa
[C204] C2 Wiki: Abstract Factory vs Factory Method. http://c2.com/cgi/wiki?AbstractFactoryVsFactoryMethod [Duell97] Duell, Michael: Non-software examples of software design patterns, Object Magazine, July 1997, pp54. [Fowler99] Fowler, Martin: Refactoring: Improving the Design of Existing Code, Adisson Wesley, 1999. [GoF95] Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995. [Kerievsky04] Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004. [Martin05] Martin, Robert: Principles, Patterns, and Practices: The Factory Pattern. http://today.java.net/pub/a/today/2005/03/09/factory.html [PPR04] C2 WikiWikiWeb: Portland Pattern Repository <en lnea>. http://c2.com/ppr/

[DPE01] Shalloway, Alan; Trott James : Design Patterns Explained : A New perspective on Object Oriented Design, Pearson Education, 2001. [Vlissides98] Vlissides, John: Pattern Hatching: Design Patterns Applied, Addison Wesley, 1998. Len Welicki es Profesor Asociado de Ingeniera Web en el Mster en Ingeniera del Software de la Universidad Pontificia de Salamanca, Madrid, Espaa; donde actualmente est realizando el Doctorado en Ingeniera Informtica, su tesis doctoral trata sobre las Arquitecturas de Software y Paradigmas No Convencionales para Ingeniera Web. Trabaja como Arquitecto de Software. Cuenta con ms de 12 aos de experiencia profesional en diversas reas de la Ingeniera del Software.