Комментарии 9
Я бы предложил Вам добавить пример для увеличения наглядности.
ага, примеры нужны. я, например, не вкурил зачем нужен плагин.
Можно автоматизировать следующие вещи:
- Автоматизированный рефакторинг существующего кода — ручками это делать всегда утомительно, да и ошибок можно внести, пока перетаскиваешь код.
- Для случая с использованием фабрик и xml-конфигурации — гарантия того, что для каждой константы и каждого интерфейса в ней предусмотрен обработчик, прописанный в xml-конфигурации.
Как всегда в декларативном программировании: если нет поддержки IDE, то гарантия консистентности превращается в ад программиста.
Статья антипод: habrahabr.ru/blogs/arbeit/99889/
Да нет, это не антипод. Перечисления — это уже не шаблон, а простая конструкция языка. Такой же, как if, else, switch.
В той статье-«антиподе» говорится, что не надо использовать сложные средства для простых задач без явной необходимости.
Из этой же статьи вообще не совсем понятно, когда использовать enum нужно и не нужно.
В той статье-«антиподе» говорится, что не надо использовать сложные средства для простых задач без явной необходимости.
Из этой же статьи вообще не совсем понятно, когда использовать enum нужно и не нужно.
Действительно, как минимум нужны примеры, иначе остаётся совершенно непонятным, что это такое и когда это нужно.
С примером полёт мысли вроде вполне понятен. Правда глядя на проблему совсем уж сверху, видна довольно узкая ниша этого решения, что впрочем автор и отмечает.
Когда-то я решал похожую(на твой пример) задачу и в итоге пришёл к выводу что в большинстве случаев когда возникают похожие проблемы/вопросы, то надо посмотреть в сторону Guice ну или прочих DI(dependency injection) фреймворков. Конечно не всегда и не каждому это подойдёт(да и не всем дадут менять настолько глобально то что и так работает), но наверное стоит отметить такой вариант тоже где-нибудь в послесловии — пусть люди смотрят уже что им лучше в каждом конкретном случае.
Когда-то я решал похожую(на твой пример) задачу и в итоге пришёл к выводу что в большинстве случаев когда возникают похожие проблемы/вопросы, то надо посмотреть в сторону Guice ну или прочих DI(dependency injection) фреймворков. Конечно не всегда и не каждому это подойдёт(да и не всем дадут менять настолько глобально то что и так работает), но наверное стоит отметить такой вариант тоже где-нибудь в послесловии — пусть люди смотрят уже что им лучше в каждом конкретном случае.
Если можно, то енумы лучше не использовать, а то код постепенно превращается в спагетти ifelse/switch выражений.
Путь правильный, только чуть-чуть не додумали. Кроме двух неочевидно необходимых интерфейсов, попали еще и на дополнительные циклические связи: если энум в одном джаре, веб в другом, а шедулер — в третьем, то ничего путного так не соберется.
Визитор (в разных видах) имхо самый элегантный способ решения проблемы декаплинга с одной стороны и компайл тайм гарантий что ничего не забыто с другой. В данном случае, к примеру, можно было бы сделать так: энум реализует интерфейс (возможность джавы, о которой незаслужено забывают) с одним методом accept(DocumentStatusVisitor). DocumentStatusVisitor — это интерфейс, объявленный в том же модуле, что и энум и в нем мы переходим от энума (конструкции процедурной) к методам (конструкции ООП) — для каждого элемента энума создаем именной метод, к примеру visitNew(), visitDraft(),… Ну что написать в имлементациях метода accept в энуме я думаю понятно.
Таким образом мы избавляемся от лишних депенденсий (энум больше не должен знать кто там и как его использует), получаем возможность держать моули раздельно, уменьшаем кол-во интерфейсов и связей.
Визитор (в разных видах) имхо самый элегантный способ решения проблемы декаплинга с одной стороны и компайл тайм гарантий что ничего не забыто с другой. В данном случае, к примеру, можно было бы сделать так: энум реализует интерфейс (возможность джавы, о которой незаслужено забывают) с одним методом accept(DocumentStatusVisitor). DocumentStatusVisitor — это интерфейс, объявленный в том же модуле, что и энум и в нем мы переходим от энума (конструкции процедурной) к методам (конструкции ООП) — для каждого элемента энума создаем именной метод, к примеру visitNew(), visitDraft(),… Ну что написать в имлементациях метода accept в энуме я думаю понятно.
Таким образом мы избавляемся от лишних депенденсий (энум больше не должен знать кто там и как его использует), получаем возможность держать моули раздельно, уменьшаем кол-во интерфейсов и связей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько слов об использовании перечислений в изменяющейся среде