Julio, miembro de este gran equipo de trabajo, nos ha hecho el favor de redactar esta sección ya que controla a la perfección el tema.
Solución:
Adaptador adapta una clase/objeto dado a una nueva interfaz. En el caso de los primeros, se suele emplear la herencia múltiple. En el último caso, el objeto se envuelve con un objeto adaptador conforme y se pasa de un lado a otro. El problema que estamos resolviendo aquí es el de interfaces no compatibles.
Fachada es más como una puerta de entrada simple a un conjunto complicado de funciones. Haces una caja negra para que tus clientes se preocupen menos, es decir simplificar las interfaces.
Apoderado proporciona la misma interfaz que la clase de proxy y, por lo general, realiza algunas tareas internas por su cuenta. (Entonces, en lugar de hacer múltiples copias de un objeto pesado X haces copias de un proxy ligero P que a su vez gestiona X y traduce sus llamadas según sea necesario.) Está resolviendo el problema del cliente de tener que manejar un objeto pesado y/o complejo.
Decorador se usa para agregar más pólvora a sus objetos (tenga en cuenta el término objetos: generalmente decora objetos dinámicamente en tiempo de ejecución). No oculta/deteriora las interfaces existentes del objeto, pero simplemente extiéndalo en tiempo de ejecución.
Ahora que tiene decorador involucrado, probablemente querrá saber por qué el énfasis en la palabra objeto: algunos lenguajes (como Java) simplemente no permiten la herencia virtual (es decir, la herencia múltiple como lo hace C ++) para permitirle lograr esto en tiempo de compilación.
Dado que hemos arrastrado múltiples herencias (y el temido diamante), buscará mezclando — que son encadenamiento lineal ordenado de interfaces para sortear los problemas de la herencia múltiple. Sin embargo, los mixins no se mezclan tan bien. Y terminamos con rasgos — si esos pequeñas manchas de comportamiento apátridas que ve una ventana emergente todo el tiempo en los parámetros de la plantilla en C++. Los rasgos intentan abordar los problemas de composición y descomposición del comportamiento de una manera elegante sin optar por herencias múltiples o encadenamiento ordenado.
Fachada
Podría usar una fachada, por ejemplo, para facilitar las llamadas a una API. Eche un vistazo a este ejemplo de una fachada remota. La idea aquí es que la implementación completa del código en el servidor esté oculta para el cliente. El cliente llama a 1 método API que, a su vez, puede realizar 1 o más llamadas API en el servidor.
Adaptador
Un buen ejemplo de esto se puede encontrar aquí, en Wikipedia. Un objeto de cliente Source me gustaría llamar a un método en otro objeto Target, pero la interfaz de ese otro objeto difiere de lo que espera el cliente.
Introduzca el objeto del adaptador.
Puede tomar una llamada desde el Source objeto y, entre bastidores, llamar al Target método que se debe utilizar.
Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)
En cuanto a Proxy, no tengo experiencia con este patrón de diseño.
Si aceptas, puedes dejar un enunciado acerca de qué te ha impresionado de esta noticia.