2015-07-11 3 views
0

Вот как я понимаю шаблон проектирования адаптерадаптер шаблон дизайна объяснил

У вас есть наследие платежной системы:

class LegacyPaymentSystem { 
    public function pay($amount) { 
    } 
    public function refund() { 
    } 
} 

Вы реализовать новую систему оплаты:

class PaymentSystem { 
    public function __construct() { 
    } 
    public function payAmount($amount, $currency) { 
    } 
    public function refund($payment_id) { 
    } 
} 

Вы используете адаптер для соединения двух. Иногда вы хотите использовать старую платежную систему.

class PaymentSystemAdapter extends PaymentSystem { 
    public function __construct($legacyPaymentSystem) { 
     $this->legacyPaymentSystem = $legacyPaymentSystem; 
    } 

    public function payAmount($amount, $currency) { 
     $this->legacyPaymentSystem->pay($amount); 
    } 
} 

Теперь клиент может сделать:

class Client { 

    public function process($amount, $currency) { 
     $legacyPaymentSystem = new LegacyPaymentSystem(); 
     $adapter = new PaymentSystemAdapter($legacyPaymentSystem); 
     $this->pay($adapter, $amount, $currency); 
    } 

    public function pay(PaymentSystem $paymentSystem, $amount, $currency) { 
     $payementSystem->payAmount($amount, $currency); 
    } 
} 

У меня есть вопрос, почему? Почему мы не можем просто позвонить в унаследованную систему платежей напрямую?

+0

Адаптер Узор действительно только о том, чтобы интерфейс одного класса, совместимого с объектом или системой, которая была разработана в а другой контракт или модель. Адаптер служит слоем между двумя объектами, переводя язык одного в другой и обратно. – scottb

ответ

0

Как правило, Client должен иметь доступ только к PaymentSystem и должен не знать о его реализации.

class Client { 

    public function process($amount, $currency) { 
     $paymentSystem = lookupPaymentSystem(); 
     $payementSystem->payAmount($amount, $currency); 
    } 
} 

Шаблон Адаптер позволяет скрыть мельчайшие различных реализаций, подвергая единый интерфейс к клиенту, несмотря на то, лежащие в основе реализации имеют различные интерфейсы.

Это позволяет придерживаться принципа разработки под названием Программа для взаимодействия, а не реализации

+0

Почему нам нужна lookupPaymentSystem? почему мы не можем просто перечислить переменную платежной системы? –

+0

Ну, метод, который передает платежную систему методу «process», мог бы вызвать «payAmount». Я имею в виду, что более корректно иметь объект и вызывать метод на нем с того же места - кажется немного странным передать объект и его параметр другому методу, а затем вызвать метод объекта. «lookupPaymentSystem» можно рассматривать как метод, который определяет, какую платежную систему использовать. Обычно, если вы работаете в системе, которая допускает инъекцию зависимостей, тогда система paymentSystem была бы введена вместо того, чтобы искать –

Смежные вопросы