Стратегия или шаблон адаптера?

Question

Стратегия или шаблон адаптера?

Я хочу создать несколько классов каждого провайдера виртуального сервера, например:

Цифровой океан
Linode
Amazon AWS

У каждого провайдера есть собственный класс PHP (через композитора) для использования их интерфейса API, я хочу использовать их библиотеку классов, но хочу убедиться, что могу использовать один и тот же метод для каждого провайдера. Например, отключение VPS:

Метод Linode API: powerOff()
Метод Digital Ocean API: haltServer()

Вместо того, чтобы использовать powerOff() а также haltServer() — я хочу использовать shutdown() Метод для любых провайдеров классов я создам. Должен ли я использовать дизайн стратегии или шаблон адаптера?

4

adapter design-patterns php strategy-pattern

Решение

Другие решения

Ответ на ваш вопрос: адаптер,
стратегия используется, когда вы можете иметь одну или несколько реализаций алгоритма.

постскриптум предложение с команда картина тоже в порядке.

1

Лучший пример дизайна Strategy ни Adaptor,
На мой взгляд, вы должны проверить Шаблон команды.

Этот шаблон решает ту же проблему, что и вы. Это обеспечит один метод, как вы просили в вашем случае shutdown и через зависимость он может вызывать любой метод, представленный зависимостью.

0

Источник

Accepted Answer

Должен ли я использовать дизайн стратегии или шаблон адаптера?

Это классическая ошибка, которую каждый допускает при разработке приложения (включая меня). Вам следует в идеале не просматривайте список доступных шаблонов проектирования и выберите тот, который лучше всего соответствует вашей проблеме. Вместо этого вы должны придумать начальный дизайн класса, а затем попытаться определить шаблон, который лучше всего описывает ваш дизайн. Это защищает вас от над-проектирование то есть создание ненужных компонентов, которые вам не требуются в противном случае. Со временем у вас скоро появится словарь шаблонов проектирования, которые вы фактически использовали, а не приложение, которое пытается использовать конкретный шаблон проектирования.

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

Вы можете достичь абстракция путем определения общего интерфейса под названием поставщик со стандартными методами работы, такими как shutdown, connect, retryи т. д. Затем можно создать один конкретный класс провайдера для каждого типа провайдера, например AWSProvider а также LinodeProvider и реализовать shutdown, connect а также retry методы. Затем вы используете Делегация вызывая специфичные для провайдера API в этих методах. Например, позвоните powerOff метод внутри shutdown метод LinodeProvider учебный класс.

Если вы теперь внимательно посмотрите на свой дизайн, вы начнете понимать, что он выглядит как стратегия так же хорошо как Aadpter шаблон. Что отличает эти две модели, так это момент времени, когда абстракция вступает в игру. Если вы решите поставщик реализация будет использоваться через завод во время выполнения приложения вы используете стратегия шаблон; однако, если это решение принято во время компиляции, вы используете адаптер шаблон. Кроме имени шаблона, ваши классы будут выглядеть примерно так же.

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

9