Patrones que vimos en clase y que llegaron a evaluarse en el 2do cuatri de 2024 de inge 1.
https://www.isw2.com.ar/ejemplos-de-la-teorica
Consiste en tener un objeto que hace de adaptador entre las interfaces de dos objetos (cliente y servicio). Hace de wrapper de su adaptee (cliente) y responde mensajes de forma que el servicio espera.
Ejemplos podrían ser un adaptador que te permite tratar un archivo json como uno XML, o un adaptador que permite ver como dibujable alguna estructura de datos o clase cualquiera.
Los adaptadores pueden ser específicos, una interfaz a otra, o genéricos, cualquier interfaz a una interfaz específica.
En Smalltalk los genéricos se instancian con un diccionario de nombre de mensaje a closure, los closures con la lógica de adaptación deseada. Luego implementan #doesNotUnderstand: de forma tal que devuelva la valuación del closure correspondiente al mensaje. El adapter sublasifica #ProtoObject para pisar la cantidad mínima de mensajes.
Consiste en extender el comportamiento de una clase sin subclasificarla.
Por ejemplo, si tuvieras que poder guardar logs de un objeto a distintos posibles destinos, que necesiten su propia lógica, un archivo en el filesystem, emails, notificaciones push.
Es un tipo de wrapper, pero se diferencia de un adaptador en que solo extiende la interfaz de un objeto, no la cambia totalmente.
Consiste en un objeto que hace de proxy de otro para controlar acceso. Se puede usar para implementar inicializaciones lazy, para cachear requests a servicios externos, etc.
En Smalltalk, un lazy init. proxy implemetaría #value así,
value
value isNil ifTrue: [ value := initClosure value ].
^value
dado un initClosure que incialice el proxee.
Un proxy puede ser polimórfico, es decir que implementa los mismos mensajes que su proxee, o genérico. En Smalltalk esto se puede lograr con meta-programación, implementando #doesNotUnderstand, y sublasificando #ProtoObject para pisar la cantidad mínima de mensajes.
Estos no los vimos en detalle con ejemplos en la teórica, pero fueron apareciendo en los ejercicios y en algunas partes de la bibliografía.
https://ubadao.wordpress.com/wp-content/uploads/2013/07/pattern-abuser.pdf
https://refactoring.guru/design-patterns
State: Objeto que representa el estado de otro. Implementa sus mensajes y los forwardea o no al objeto que representa según como lo implemente. Por ej. #BankAccountState con subclases #Closed, #Overdrawn, #Open, solo la última dejaría pasar un #withdraw.
Strategy: Clase con subclases que implementan sus mensajes de distinta forma (por ej. distintos algorítmos para un calculo), pero de forma polimórfica.
Chain of reponsability: Agrupar instancias para que el agrupador decida quien handelear los mensajes que le llegan. Ej. #Porfolio decide que cuenta que agrupa handelea un #withdraw.
Composite: Agrupar objetos en forma de árbol para poder tratarlos como un solo objeto.
Iterator: Objeto que recorre cosas iterables, como composites.
Visitor: Aplicar un proceso a una estructura visitable entera.
Observer: Objeto que observa cambios en otro objeto y que notifica a sus suscriptores acerca de ellos.
Façade: Interfaz simplificada para otra clase o serie de clases.
Bridge: TODO.
Abstract factory: TODO.
Builder: TODO.
Factory method: TODO.
Prototype: TODO.
© 2020-2025 Ramiro. Contenido disponible bajo CC BY-SA 4.0.