Когда использовать шаблонный метод По сравнению со Стратегией?
Я предполагаю, что многие люди приходят сюда из-за названия и потому, что API HttpConnectionParams устарел.
Используя последнюю версию HTTP-клиента Apache, вы можете установить эти таймауты, используя параметры запроса:
HttpPost request = new HttpPost(url);
RequestConfig requestConfig = RequestConfig.custom()
.setSocketTimeout(TIMEOUT_MILLIS)
.setConnectTimeout(TIMEOUT_MILLIS)
.setConnectionRequestTimeout(TIMEOUT_MILLIS)
.build();
request.setConfig(requestConfig);
В качестве альтернативы вы также можете установить это при создании своего HTTP-клиента, используя API-интерфейс Builder для HTTP-клиента, но вам также потребуется создать настраиваемый диспетчер подключений с настраиваемой конфигурацией сокета .
Файл примера конфигурации - отличный ресурс, чтобы узнать, как настроить Apache HTTP Client.
6 ответов
Я использую Шаблонный метод, когда для алгоритма нужно знание внутренностей объектов, это работает.
Во всех других случаях (т.е. когда алгоритм только должен использовать интерфейс объекта), я пытаюсь использовать Стратегию.
Далее, Стратегия только полезна, когда существуют фактические алгоритмы для реализации: Если единственная разница между классами (например), что простое значение возвратиться, используйте Шаблонный метод.
Стратегия позволяет, чтобы допускающий повторное использование алгоритм использовался больше чем в одном месте. Если у Вас есть алгоритм, который может быть предоставлен Вашим потребителем и может использоваться в нескольких местах, это - хорошее место для Стратегии (сортирующий алгоритмы, предикаты, компараторы... являются хорошими примерами этого).
Шаблонный метод конкретно предназначен для случаев, где Вы хотите, чтобы люди были в состоянии наследоваться Вашему классу и хотеть, чтобы они были в состоянии переопределить Вашу реализацию управляемым способом (в основном препятствующий тому, чтобы они заменять весь Ваш инфраструктура и предложение они определенный точка расширения, рискующий проблема, потому что они не назвали базовый метод или назвали его не в то время).
Они могут быть подобными, и они могут служить тому же виду цели в зависимости от того, что Вы на самом деле делаете. Как со всеми шаблонами разработки, трудно ответить на такой вопрос, потому что нет действительно категорического ответа. На самом деле легче решить в контексте...
Рассмотрите стратегию использования когда:
- Ваше поведение объекта должно быть изменено во времени выполнения.
- у Вас уже есть иерархия классов по другим критериям.
- Вы хотите совместно использовать логику стратегии через различные классы.
В других случаях должно быть достаточно использовать шаблонный шаблон.
Вы можете создать большое дерево наследования просто для изменения одного из N поведения. И вы можете создать второе большое дерево наследования, чтобы изменить второе из N поведения.
Но вы также можете разгрузить свое дерево, создав маленькие деревья стратегий.
Так что, если вы заметили, что добавляете все больше и больше классов просто для того, чтобы добавить некоторые изменения в какое-то поведение - пришло время снабдить ваши классы стратегиями.
Один из центральных принципов ОО-дизайна - «Состав предпочтения по сравнению с наследованием», что позволяет предпочесть шаблон «Стратегия». Очевидно, это зависит от того, чего вы пытаетесь достичь в конкретном сценарии.
Эти два могут на самом деле использоваться вместе вполне эффективно.
Не думайте о шаблонах как о рецептах с определенным кодом для реализации их.
Это - намерение дизайна, которое является ключом, и может быть много реализаций. Путем упоминания шаблона называют в коде где-нибудь, Вы впускаете читателя на своем намерении при написании того кода. Реализация вторична.
Шаблонный метод дает Вам "алгоритм с заменимыми шагами". (Алгоритм обычно определяется в непереопределяемом методе (окончательный или частный, например)),
Реализация GoF этого понятия использует наследование и переопределение метода для замены тех шагов.
Однако Вы все еще используете Шаблонный метод, если те шаги заменяются стратегиями.
Например, думайте о классе, который хочет обойти двоичное дерево inorder, и "делают что-то" в каждом узле.
Намерение состоит в том, что inorder () метод является шаблонным методом - структура обхода всегда является тем же.
Метод "рычага", часть, которая "делает что-то", может быть реализован как метод в том же классе (и переопределен в подклассах для изменения поведения), или внешне, в этом случае это - стратегия того, чтобы "сделать что-то".