Este patrn particular se puede utilizar cuando su cdigo depende de alguna API externa, o de
cualquier otra clase propensa a cambiar con frecuencia. Este patrn cae bajo la categora de
"patrones estructurales" porque nos ensea cmo nuestro cdigo y nuestras clases deben ser
estructurados con el fin de administrarlos y / o ampliarlos fcilmente.
Una vez ms, me gustara reiterar que los patrones de diseo no tienen nada nuevo sobre las
clases tradicionales. En cambio, nos muestran una mejor manera de estructurar nuestras clases,
manejar su comportamiento y administrar su creacin.
En el cdigo anterior, puede ver que estamos utilizando una clase de PayPal para pagar
simplemente la cantidad. Aqu, estamos creando directamente el objeto de la clase PayPal y
pagando a travs de PayPal. Tienes este cdigo disperso en varios lugares. As podemos ver que el
cdigo est usando el $ paypal-> sendPayment ('amount here'); Mtodo de pago.
Hace algn tiempo, PayPal cambi el nombre del mtodo API de sendPayment a payAmount. Esto
debera indicar claramente un problema para aquellos de nosotros que han estado utilizando el
mtodo sendPayment. Especficamente, necesitamos cambiar todas las llamadas de mtodo
sendPayment a payAmount. Imagnese la cantidad de cdigo que debemos cambiar y el tiempo
que necesitamos para probar cada una de las caractersticas una vez ms.
Una solucin a este problema es utilizar el patrn de diseo del adaptador.
Segn Wikipedia:
En la ingeniera de software, el patrn de adaptador es un patrn de diseo de software que
permite utilizar la interfaz de una clase existente desde otra interfaz. A menudo se utiliza para que
las clases existentes funcionen con otras personas sin modificar su cdigo fuente.
En este caso, debemos crear una interfaz de envoltura que hace esto posible. No haremos ningn
cambio en la biblioteca de clases externa porque no tenemos control sobre ella y puede cambiar
en cualquier momento.