Factory method (Gamma et al.) Define una interfaz para crear un objeto pero deja a las subclases decidir que clase instanciar Motivación: Consideremos un framework que presenta múltiples documentos al usuario. Aquí aparecen dos abstracciones claves: Aplicación y Documento. Ambas clases son abstractas y los clientes deben crear las subclases respectivas para realizar sus implementaciones dependientes de la aplicación. Dado que la subclase particular de Documento a instanciar es dependiente de la aplicación, la clase Aplicación no puede predecir qué subclase Documento instanciar: la clase Aplicación sólo sabe cuando un nuevo documento debe ser instanciado pero no cuál. FactoryMethod provee una solución: encapsula el conocimiento de qué subclase de Documento crear y lo mueve fuera del framework.
Factory method Ejemplo: Las subclases de Aplicación redefinen CreateDocument para retornar la subclase de Documento apropiada
Factory method Estructura: Aplicabilidad: -Una clase no puede anticipar el tipo de objetos que debe crear -Una clase quiere que sus subclases especifiquen el objeto a crear
Factory method Otros usos: Conecta jerarquías paralelas
Implementaciones: Factory method - Variaciones: (a) La clase Creator es una clase abstracta y no provee una implementación del factory method que declara, (b) La clase Creator es una clase concreta y provee una implementación default. - Factory methods parametrizados: Un factory method puede crear múltiples productos si recibe como parámetro un valor que identifica el tipo de objeto a crear. class Creator{ public: virtual Product* create(productid); } Product* Creator::create(ProductId id){ if( id == ID_1){ return ID_1Product;} if( id == ID_2){ return ID_2Product;}... return 0; }
Factory method Redefiniendo un factory method parametrizado nos permite extender fácilmente la creación a incorporar nuevos productos o cambiar los productos que el Creador genera. class MyCreator: public Creator{ public: virtual Product* create(productid);} Product* MyCreator::create(ProductId id){ if( id == ID_1){ return ID_2Product;} if( id == ID_2){ return ID_1Product;}... if( id == ID_N){ return ID_NProduct;} return Creator::create(id); }
Iterator(continuación) AbstractList provee una interfaz común para manipular listas. Un iterador abstracto define una una interfaz de iteración común. El mecanismo de iteración es independiente de las clases agregadas concretas. Si se desea escribir código independiente de las subclases concretas, es conveniente tener un método createiterator() para solicitar el iterador a usar. Qué tipo de método es éste?
Iterator( cont.) Estructura:
Iterator(cont.) Implementaciones: - Quién controla la iteración? Si el cliente la controla se habla de iteradores externos y si el mimo iterador la controla de conocen como iteradores internos. Cuáles son más flexibles? Los externos. - Iteradores internos: cómo parametrizar el iterador con la operación que aplicar a cada elemento? template<class Item> class ListTraverser{ public: ListTraverser(List<Item*> alist); bool Traverse(); protected: virtual bool processitem(const Item); private: ListIterator<Item> _iterator; }
Iterator(cont.) template <class Item> ListTraverser<Item>::ListTraverser( List<Item>* alist):_iterator(alist){} template <class Item> bool ListTraverser<Item>::Traverse(){ bool result = false; for( iterator.first();!iterator.isdone(); _iterator.next()){ result = ProcessItem(_iterator.CurrentItem() ); if( result == false ) break; } return result; } Nota: Internamente usa un iterador externo para su recorrido.
Iterator (cont.) Ejemplo: Usarlo para imprimir los primeros diez empleados de una listade empleados. class PrintNEmployees: public ListTraverser<Employee*>{ public: PrintNEmployees(List<Employee*>* alist, int n): ListTraverser<Employee*>(aList), _total(n), _count(0){} protected: bool ProcessItem(const Employee*); private: int _total; int _count; }; bool PrintNEmployees::ProcessItem(const Employee* e){ _count++; e->print(); return _count < _total; }
Iterator (cont.) Uso: List<Employess*>* employees; //... PrintNEmployees pa(employees,10); pa.traverse(); El beneficio es que la lógica entera de la iteración puede ser reusada. Nota: Los iteradores internos pueden ser extendidos para procesar sólo los elementos si satisfacen un cierto test. Para esto junto al método para procesar Item, debe existir uno llamado TestItem(...).
Composite Modela objetos en estructuras de árbol para representar jerarquías parte-todo. - Los clientes deben ser capaces de ignorar la diferencia entre objetos compuestos y objetos individuales. Estructura:
Composite Implementación: Notar que este patrón incluye una contradicción. - El patrón hace que los clientes se olviden de las diferencias entre clases primitivas y clases compuestas. Para esto todas tienen la misma interfaz. Problema? Este diseño va en contra del principio que dice que cada clase debe tener las operaciones que tienen significado para ella. En este caso, getchild, add, remove solo tienen sentido para las subclases de Composite. - Qué implementación default podemos dar para cada una? + getchild: Si definimos que una hoja(leaf) como una componente sin hijos, podemos definir una operación default de acceso a los hijos que nunca retorna hijos. + add, remove? No se ve de manera natural
Composite - Veamos ventajas/desventajas del diseño en general: + definir estas operaciones en la raiz de la jerarquía (Component) da transparencia pues todo se maneja de manera uniforme, pero es menos segura pues los clientes pueden querer hacer add y remove de algo que no tiene sentido. + definirlas sólo en la clase Composite es más seguro pero se pierde uniformidad. + Conflicto entre transparencia y seguridad. Si optamos por seguridad en algún momento hay que usar cast: (Composite) componente. Esto tambien puede llevar a errores por eso este patrón decidió enfatizar transparencia. Recomendación: optar por seguridad agregando un método getcomposite() que retorna null si es hoja y retorna this si es compuesto. El cliente entonces agrega una nueva componente con add solo si corresponde.
Composite class Component{ public: //... virtual Composite* getcomposite(){return 0;} }; class Composite: public Component{ public: void add(component*); //... virtual Composite* getcomposite(){ return this;} }; class Leaf: public Component{ //... }
Composite Uso: Composite* acomposite = new Composite(); Leaf* aleaf = new Leaf(); Component* acomponent; Composite* test; acomponent = acomposite; if( test = acomponent->getcomposite() ){ test->add(new Leaf()); } acomponent = aleaf; if( test = acomponent->getcomposite() ){ test->add(new Leaf()); // No se agrega }