Padrão do adaptador - Adapter pattern

Na engenharia de software , o padrão do adaptador é um padrão de design de software (também conhecido como wrapper , uma nomenclatura alternativa compartilhada com o padrão decorador ) que permite que a interface de uma classe existente seja usada como outra interface. Geralmente é usado para fazer as classes existentes funcionarem com outras, sem modificar seu código-fonte .

Um exemplo é um adaptador que converte a interface de um Document Object Model de um documento XML em uma estrutura de árvore que pode ser exibida.

Visão geral

O padrão de design do adaptador é um dos vinte e três padrões de design conhecidos da Gang of Four que descrevem como resolver problemas de design recorrentes para projetar software orientado a objetos flexível e reutilizável, ou seja, objetos que são mais fáceis de implementar, alterar, testar e reutilizar.

O padrão de design do adaptador resolve problemas como:

  • Como pode ser reutilizada uma classe que não possui uma interface exigida por um cliente?
  • Como as classes com interfaces incompatíveis podem trabalhar juntas?
  • Como uma interface alternativa pode ser fornecida para uma classe?

Freqüentemente, uma classe (já existente) não pode ser reutilizada apenas porque sua interface não está em conformidade com a interface que os clientes exigem.

O padrão de design do adaptador descreve como resolver esses problemas:

  • Defina uma adapterclasse separada que converta a interface (incompatível) de uma classe ( adaptee) em outra interface ( target) exigida pelos clientes.
  • Trabalhe por meio de adapterclasses para trabalhar (reutilizar) que não possuem a interface necessária.

A ideia principal neste padrão é trabalhar por meio de uma adapterclasse separada que adapte a interface de uma classe (já existente) sem alterá-la.

Os clientes não sabem se trabalham com uma targetclasse diretamente ou por meio de uma adapterclasse que não possui a targetinterface.

Veja também o diagrama de classes UML abaixo.

Definição

Um adaptador permite que duas interfaces incompatíveis funcionem juntas. Esta é a definição do mundo real para um adaptador. As interfaces podem ser incompatíveis, mas a funcionalidade interna deve atender à necessidade. O padrão de design do adaptador permite que classes incompatíveis trabalhem juntas, convertendo a interface de uma classe em uma interface esperada pelos clientes.

Uso

Um adaptador pode ser usado quando o wrapper deve respeitar uma interface específica e deve suportar comportamento polimórfico . Como alternativa, um decorador torna possível adicionar ou alterar o comportamento de uma interface em tempo de execução, e uma fachada é usada quando uma interface mais fácil ou mais simples para um objeto subjacente é desejada.

Padrão Intenção
Adaptador ou invólucro Converte uma interface em outra para que corresponda ao que o cliente espera
Decorador Adiciona responsabilidade dinamicamente à interface, envolvendo o código original
Delegação Suporte "composição sobre herança"
Fachada Fornece uma interface simplificada

Estrutura

Diagrama de classe UML

Um diagrama de classe UML de amostra para o padrão de design do adaptador.

No diagrama de classes UML acima , a clientclasse que requer uma targetinterface não pode reutilizar a adapteeclasse diretamente porque sua interface não está em conformidade com a targetinterface. Em vez disso, o clientfunciona por meio de uma adapterclasse que implementa a targetinterface em termos de adaptee:

  • A object adaptermaneira implementa a targetinterface delegando a um adapteeobjeto em tempo de execução ( adaptee.specificOperation()).
  • A class adaptermaneira como implementa a targetinterface herdando de uma adapteeclasse em tempo de compilação ( specificOperation()).

Padrão de adaptador de objeto

Nesse padrão de adaptador, o adaptador contém uma instância da classe que envolve. Nessa situação, o adaptador faz chamadas para a instância do objeto empacotado .

O padrão do adaptador de objeto expresso em UML
O padrão do adaptador de objeto expresso em LePUS3

Padrão do adaptador de classe

Este padrão de adaptador usa várias interfaces polimórficas implementando ou herdando tanto a interface que é esperada quanto a interface que é pré-existente. É típico que a interface esperada seja criada como uma classe de interface pura , especialmente em linguagens como Java (antes do JDK 1.8) que não suportam herança múltipla de classes.

O padrão do adaptador de classe expresso em UML .
O padrão do adaptador de classe expresso em LePUS3

Uma outra forma de padrão de adaptador de tempo de execução

Motivação da solução de tempo de compilação

Deseja- classAse fornecer classBalguns dados, suponhamos alguns Stringdados. Uma solução de tempo de compilação é:

classB.setStringData(classA.getStringData());

No entanto, suponha que o formato dos dados da string deva ser variado. Uma solução de tempo de compilação é usar herança:

public class Format1ClassA extends ClassA {
    @Override
    public String getStringData() {
        return format(toString());
    }
}

e talvez crie o objeto de "formatação" correta em tempo de execução por meio do padrão de fábrica .

Solução de adaptador de tempo de execução

Uma solução usando "adaptadores" procede da seguinte forma:

  1. Defina uma interface de "provedor" intermediária e escreva uma implementação dessa interface de provedor que envolva a fonte dos dados, ClassAneste exemplo, e produza os dados formatados conforme apropriado:
    public interface StringProvider {
        public String getStringData();
    }
    
    public class ClassAFormat1 implements StringProvider {
        private ClassA classA = null;
    
        public ClassAFormat1(final ClassA a) {
            classA = a;
        }
    
        public String getStringData() {
            return format(classA.getStringData());
        }
    
        private String format(final String sourceValue) {
            // Manipulate the source string into a format required 
            // by the object needing the source object's data
            return sourceValue.trim();
        }
    }
    
  2. Escreva uma classe de adaptador que retorne a implementação específica do provedor:
    public class ClassAFormat1Adapter extends Adapter {
        public Object adapt(final Object anObject) {
            return new ClassAFormat1((ClassA) anObject);
        }
    }
    
  3. Registre o adaptercom um registro global, para que adapterpossa ser consultado no tempo de execução:
    AdapterFactory.getInstance().registerAdapter(ClassA.class, ClassAFormat1Adapter.class, "format1");
    
  4. No código, ao desejar transferir dados de ClassApara ClassB, escreva:
    Adapter adapter =
        AdapterFactory.getInstance()
            .getAdapterFromTo(ClassA.class, StringProvider.class, "format1");
    StringProvider provider = (StringProvider) adapter.adapt(classA);
    String string = provider.getStringData();
    classB.setStringData(string);
    

    ou mais concisamente:

    classB.setStringData(
        ((StringProvider)
                AdapterFactory.getInstance()
                    .getAdapterFromTo(ClassA.class, StringProvider.class, "format1")
                    .adapt(classA))
            .getStringData());
    
  5. A vantagem é que, se se deseja transferir os dados em um segundo formato, procure o adaptador / provedor diferente:
    Adapter adapter =
        AdapterFactory.getInstance()
            .getAdapterFromTo(ClassA.class, StringProvider.class, "format2");
    
  6. E se for desejado produzir os dados ClassAcomo, digamos, dados de imagem em : Class C
    Adapter adapter =
        AdapterFactory.getInstance()
            .getAdapterFromTo(ClassA.class, ImageProvider.class, "format2");
    ImageProvider provider = (ImageProvider) adapter.adapt(classA);
    classC.setImage(provider.getImage());
    
  7. Dessa forma, o uso de adaptadores e provedores permite várias "visualizações" por ClassBe ClassCpara ClassAsem ter que alterar a hierarquia de classes. Em geral, permite um mecanismo para fluxos de dados arbitrários entre objetos que podem ser adaptados a uma hierarquia de objetos existente.

Implementação do padrão do adaptador

Ao implementar o padrão do adaptador, para maior clareza, pode-se aplicar o nome da classe à implementação do provedor; por exemplo ,. Deve ter um método construtor com uma variável de classe adaptee como parâmetro. Este parâmetro será passado para um membro de instância de . Quando o clientMethod é chamado, ele terá acesso à instância do adaptee que permite acessar os dados necessários do adaptee e realizar operações nesses dados que geram a saída desejada. [ClassName]To[Interface]AdapterDAOToProviderAdapter[ClassName]To[Interface]Adapter

Java

interface LightningPhone {
    void recharge();
    void useLightning();
}

interface MicroUsbPhone {
    void recharge();
    void useMicroUsb();
}

class Iphone implements LightningPhone {
    private boolean connector;

    @Override
    public void useLightning() {
        connector = true;
        System.out.println("Lightning connected");
    }

    @Override
    public void recharge() {
        if (connector) {
            System.out.println("Recharge started");
            System.out.println("Recharge finished");
        } else {
            System.out.println("Connect Lightning first");
        }
    }
}

class Android implements MicroUsbPhone {
    private boolean connector;

    @Override
    public void useMicroUsb() {
        connector = true;
        System.out.println("MicroUsb connected");
    }

    @Override
    public void recharge() {
        if (connector) {
            System.out.println("Recharge started");
            System.out.println("Recharge finished");
        } else {
            System.out.println("Connect MicroUsb first");
        }
    }
}
/* exposing the target interface while wrapping source object */
class LightningToMicroUsbAdapter implements MicroUsbPhone {
    private final LightningPhone lightningPhone;

    public LightningToMicroUsbAdapter(LightningPhone lightningPhone) {
        this.lightningPhone = lightningPhone;
    }

    @Override
    public void useMicroUsb() {
        System.out.println("MicroUsb connected");
        lightningPhone.useLightning();
    }

    @Override
    public void recharge() {
        lightningPhone.recharge();
    }
}

public class AdapterDemo {
    static void rechargeMicroUsbPhone(MicroUsbPhone phone) {
        phone.useMicroUsb();
        phone.recharge();
    }

    static void rechargeLightningPhone(LightningPhone phone) {
        phone.useLightning();
        phone.recharge();
    }

    public static void main(String[] args) {
        Android android = new Android();
        Iphone iPhone = new Iphone();

        System.out.println("Recharging android with MicroUsb");
        rechargeMicroUsbPhone(android);

        System.out.println("Recharging iPhone with Lightning");
        rechargeLightningPhone(iPhone);

        System.out.println("Recharging iPhone with MicroUsb");
        rechargeMicroUsbPhone(new LightningToMicroUsbAdapter (iPhone));
    }
}

Saída

Recharging android with MicroUsb
MicroUsb connected
Recharge started
Recharge finished
Recharging iPhone with Lightning
Lightning connected
Recharge started
Recharge finished
Recharging iPhone with MicroUsb
MicroUsb connected
Lightning connected
Recharge started
Recharge finished

Pitão

"""
Adapter pattern example.
"""
from abc import ABCMeta, abstractmethod

NOT_IMPLEMENTED = "You should implement this."

RECHARGE = ["Recharge started.", "Recharge finished."]

POWER_ADAPTERS = {"Android": "MicroUSB", "iPhone": "Lightning"}

CONNECTED = "{} connected."
CONNECT_FIRST = "Connect {} first."

class RechargeTemplate:
    __metaclass__ = ABCMeta

    @abstractmethod
    def recharge(self):
        raise NotImplementedError(NOT_IMPLEMENTED)

class FormatIPhone(RechargeTemplate):
    @abstractmethod
    def use_lightning(self):
        raise NotImplementedError(NOT_IMPLEMENTED)

class FormatAndroid(RechargeTemplate):
    @abstractmethod
    def use_micro_usb(self):
        raise NotImplementedError(NOT_IMPLEMENTED)

class IPhone(FormatIPhone):
    __name__ = "iPhone"

    def __init__(self):
        self.connector = False

    def use_lightning(self):
        self.connector = True
        print(CONNECTED.format(POWER_ADAPTERS[self.__name__]))

    def recharge(self):
        if self.connector:
            for state in RECHARGE:
                print(state)
        else:
            print(CONNECT_FIRST.format(POWER_ADAPTERS[self.__name__]))

class Android(FormatAndroid):
    __name__ = "Android"

    def __init__(self):
        self.connector = False

    def use_micro_usb(self):
        self.connector = True
        print(CONNECTED.format(POWER_ADAPTERS[self.__name__]))

    def recharge(self):
        if self.connector:
            for state in RECHARGE:
                print(state)
        else:
            print(CONNECT_FIRST.format(POWER_ADAPTERS[self.__name__]))

class IPhoneAdapter(FormatAndroid):
    def __init__(self, mobile):
        self.mobile = mobile

    def recharge(self):
        self.mobile.recharge()

    def use_micro_usb(self):
        print(CONNECTED.format(POWER_ADAPTERS["Android"]))
        self.mobile.use_lightning()

class AndroidRecharger:
    def __init__(self):
        self.phone = Android()
        self.phone.use_micro_usb()
        self.phone.recharge()

class IPhoneMicroUSBRecharger:
    def __init__(self):
        self.phone = IPhone()
        self.phone_adapter = IPhoneAdapter(self.phone)
        self.phone_adapter.use_micro_usb()
        self.phone_adapter.recharge()

class IPhoneRecharger:
    def __init__(self):
        self.phone = IPhone()
        self.phone.use_lightning()
        self.phone.recharge()

print("Recharging Android with MicroUSB recharger.")
AndroidRecharger()
print()

print("Recharging iPhone with MicroUSB using adapter pattern.")
IPhoneMicroUSBRecharger()
print()

print("Recharging iPhone with iPhone recharger.")
IPhoneRecharger()

C #

public interface ILightningPhone
{
	void ConnectLightning();
	void Recharge();
}

public interface IUsbPhone
{
	void ConnectUsb();
	void Recharge();
}

public sealed class AndroidPhone : IUsbPhone
{
	private bool isConnected;
	
	public void ConnectUsb()
	{
		this.isConnected = true;
		Console.WriteLine("Android phone connected.");
	}

	public void Recharge()
	{
		if (this.isConnected)
		{
			Console.WriteLine("Android phone recharging.");
		}
		else
		{
			Console.WriteLine("Connect the USB cable first.");
		}
	}
}

public sealed class ApplePhone : ILightningPhone
{
	private bool isConnected;
	
	public void ConnectLightning()
	{
		this.isConnected = true;
		Console.WriteLine("Apple phone connected.");
	}

	public void Recharge()
	{
		if (this.isConnected)
		{
			Console.WriteLine("Apple phone recharging.");
		}
		else
		{
			Console.WriteLine("Connect the Lightning cable first.");
		}
	}
}

public sealed class LightningToUsbAdapter : IUsbPhone
{
	private readonly ILightningPhone lightningPhone;
	
	private bool isConnected;
	
	public LightningToUsbAdapter(ILightningPhone lightningPhone)
	{
		this.lightningPhone = lightningPhone;
		this.lightningPhone.ConnectLightning();
	}
	
	public void ConnectUsb()
	{
		this.isConnected = true;
		Console.WriteLine("Adapter cable connected.");
	}

	public void Recharge()
	{
		if (this.isConnected)
		{
			this.lightningPhone.Recharge();
		}
		else
		{
			Console.WriteLine("Connect the USB cable first.");
		}
	}
}

public void Main()
{
	ILightningPhone applePhone = new ApplePhone();
	IUsbPhone adapterCable = new LightningToUsbAdapter(applePhone);
	adapterCable.ConnectUsb();
	adapterCable.Recharge();
}

Saída:

Apple phone connected.
Adapter cable connected.
Apple phone recharging.

Veja também

Referências