Абстрактный класс Java или статическое служебное проектное решение класса
Я реализую несколько стратегий (Стратегическая модель), которые имеют некоторое общее поведение, и не решено, где общие операции должны жить.
- При принятии контекста I 1 и 3 стратегий, совместно используются некоторые операции, используемые в стратегиях, некоторые необходимы только 2 другими просто быть 1 из стратегий.
- Нет никакого членского совместно использованного состояния уровня, поэтому единственные операции являются эффективно не сохраняющими состояние.
- Намерение операций состоит в том, чтобы поддерживать форматирование состояния в файл, как помощник представления.
Опция 1: Сделайте класс AbstractStrategy
- Я использую Java, таким образом, это сразу устраняет использование этой функции в будущем.
- Наследование имеет тенденцию заканчиваться. в гребенчатой структуре.
- Операции были бы окончательными.
Опция 2: Создайте класс Util статических помощников
- Гибкий, но чувствует себя подобно запаху кода по некоторым причинам.
- Не остроконечный.
Какие-либо рекомендации или предпочтения?
Отметьте уровень, в котором я работаю, уровень Стратегии, не уровень Контекста (см., что Википедия связывается).
4 ответа
Есть одна причина ... одна огромная причина ... использовать статический класс Util вместо абстрактного класса или интерфейса.
Так что вы можете добавить больше методов позже.
В случае абстрактного класса или интерфейса любое изменение, которое вы вносите в этот класс / интерфейс, должно быть изменено во всех классах, которые унаследованы от него. Это особенно проблематично, если вы пишете публичный API.
В структуре Java есть служебные классы со статическими методами, разбросанными по всему сайту. Наиболее известные из них находятся в пакете java.util : Коллекции и Массивы .
Есть много способов добиться этого.
Используйте абстрактный класс и превратите переменные части выполнения в абстрактные методы. => Некоторые стратегии будут реализовывать все операции (путем переопределения абстрактных методов), в то время как другие могут пропускать необязательные. Обратите внимание, что в этом случае необязательные операции могут быть пустыми методами перехвата, а не абстрактными методами. Таким образом вы избежите проблем, связанных с реализацией этих операций как пустых методов в подклассе.
Используйте реальный интерфейс «Стратегии» (с методом execute, как в статье в Википедии, на которую вы указали). Затем клиентский класс будет предоставлен реализацией стратегии (может быть анонимным внутренним классом или реальным классом полноценной стратегии).
Первый более простой, но более жесткий: если вам нужно изменить количество операций (особенно абстрактных), необходимо обновить все подклассы.
Второй вариант более гибкий, но вам нужно будет найти способ «разделить» общие операции между разными стратегиями путем делегирования или использования статических служебных методов.
Есть еще один вариант в дополнение к двум, которые вы перечислили:
Мне кажется, вам нужна какая-то композиция, в которой вы можете использовать только ту функциональность, которая вам нужна. Возможно, вы могли бы упаковать свои операции, используя шаблон команд, а затем собрать из них свои стратегии?
Преимущества:
- Наследование стратегии не требуется.
- Стратегии не будут видны неиспользуемые / скрытые «общие методы».
- Нет статического служебного класса с набором (возможно) несвязанных методов.
- Упрощение модульного тестирования - операции можно тестировать изолированно.
- Простой общий класс стратегии, который выполняет итерацию операций.
Недостатки:
- Дополнительные занятия.
- Операции должны соответствовать общему командному интерфейсу, который может быть ограничительным.
- Может оказаться излишним для очень простых операций - какими могут быть ваши форматеры.
если она объявлена как Abstract, люди могут догадаться, что она предназначена для расширения. Поэтому лучше объявить частный конструктор.