Перечислимые объекты должны быть не сохраняющими состояние?
Вам не нужны подготовленные операторы, если запрос не ожидает пользовательских аргументов.
6 ответов
Я думаю, что это нарушает Принцип Наименьшего количества Удивления.
Люди ожидают общее использование перечислений, поскольку они были первоначально разработаны - как константы или маркеры, и не как классы общего назначения с состоянием.
Да. И 'да' я имею в виду 'Всегда'.
Если Вы хотите сопоставить статистику на количестве названных операций, реализуйте некоторую наблюдательность.
Котенок умирает каждый раз, когда Вы создаете изменяемое перечисление. Сохраните котят!
Это походит на плохое использование для перечислений - почему не только идут с основным абстрактным классом с новым подклассом для каждой операции?
Любая форма изменяемых помех является грехом. (Ну, Вам могли бы сойти с рук нетекучие кэши, некоторая ленивая инициализация и формы входа.)
Я полностью соглашаюсь с mparaz, что он нарушает Принцип Наименьшего количества Удивления. Люди ожидают, что перечисления будут константами.
Можно почти наверняка работать вокруг регистрирующейся вещи чем-то как:
DO_THIS() {
public Result doSomething(Object theData) {
MyUtilClass.doSomething(Object theData);
}
}
и помещенный Ваш вход в систему другого класса.
ОДНАКО, если Вы не можете работать вокруг этого, Принцип Наименьшего количества Удивления является инструкцией; можно нарушить его, ЕСЛИ Вы даете пользователям класса достаточно предупреждений о том, что продолжается. Удостоверьтесь, что Перечислимое объявление содержит БОЛЬШОЕ уведомление, говоря, что это изменяемо, и описание точно, какова переменчивость. Перечисление должно все еще работать; это делает ссылочное сравнение с к единственному экземпляру для тестирования перечислимых значений.