Выбор класса абстрактного Java-класса или класса статической служебной программы

Question

Я реализую несколько стратегий (шаблон стратегии) ​​, которые имеют некоторое общее поведение и не знаю, где должны жить общие операции.

• Предполагая, что у меня 1 контекст и 3 стратегиинекоторые операции, используемые в стратегиях, являются общими, некоторые необходимы только двум другим, а только одной из стратегий.
• Нет общего состояния на уровне элемента, поэтому единственные операции фактически не имеют состояния.
• Целью операций является поддержка форматирования состояния в файл, например, помощник вида.

Вариант 1: Создать класс AbstractStrategy

• Я использую Java, поэтому использование этой функции в будущем сразу же отнимает.
• Наследование имеет тенденцию к результату.в ребристой структуре.
• Операции будут окончательными.

Вариант 2. Создание класса статических помощников Util

• Гибкий, но по какой-то причине кажется, что запах кодаУровень стратегии, а не уровень контекста (см. Ссылку в Википедии).

Answer 1

Есть одна причина ... одна огромная причина ... использовать статический класс Util над абстрактным классом или интерфейсом.

Таким образом, вы можете добавить больше методов позже.date.

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

В среде Java есть классы util с разбросанными по всему объему статическими методами.Наиболее известные из них находятся в пакете java.util: Collections и Arrays.

Answer 2

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

Answer 3

Существует еще один вариант, помимо двух, которые вы перечислили:

Мне кажется, что вам нужна какая-то композиция, в которой вы можете использовать только те функции, которые вам нужны. Возможно, вы могли бы упаковать свои операции, используя шаблон команд, а затем собрать свои стратегии из них?

Преимущества:

• Стратегия наследования не требуется.
• Стратегии не будут отображать неиспользуемые / скрытые «общие методы».
• Нет статического служебного класса с перемешиванием (возможно) несвязанных методов.
• Упростить до модульного тестирования - операции можно тестировать изолированно.
• Простой класс совместно используемой стратегии, который перебирает операции.

Недостатки:

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

Answer 4

Есть много способов достичь этого.

1. Использовать абстрактный класс и превратить переменные части выполнения в абстрактные методы => Некоторые стратегии реализуют все операции (переопределяяабстрактные методы), в то время как другие могут пропустить дополнительные.Обратите внимание, что в этом случае необязательные операции могут быть пустыми подключаемыми методами, а не абстрактными методами.Таким образом, вы избежите необходимости реализовывать эти операции как пустые методы в подклассе.

2. Используйте фактический интерфейс «Стратегия» (с методом execute, как в статье в Википедии, которую вы указалик).Клиентский класс будет затем обеспечен реализацией стратегии (может быть анонимным внутренним классом или фактически полноценным классом стратегии).

Первый более простой, но более жесткий:если вам нужно изменить количество операций (особенно абстрактных), все подклассы должны быть обновлены.

Второй более гибкий, но вам нужно будет найти способ «поделиться» общими операциямимежду различными стратегиями путем делегирования или использования статических служебных методов.