4 причины использовать перечисления PHP вместо старомодных констант класса.
Пользуетесь константами класса? Пора узнать о четырех веских причинах перехода на перечисления, которые появились в PHP два года назад. 1) Встроенный метод «cases»
Раньше в проекте с разными статусами пользователей — одни из которых активные, другие забаненные, а у третьих не завершена регистрация — эти состояния обрабатывались константами класса, что приводило к такому коду:
Почему здесь метод all? Потому что выпадающий списо?
4 причины использовать перечисления PHP вместо старомодных констант класса...
Пользуетесь константами класса? Пора узнать о четырех веских причинах перехода на перечисления, которые появились в PHP два года назад.
1) Встроенный метод «cases»
Раньше в проекте с разными статусами пользователей — одни из которых активные, другие забаненные, а у третьих не завершена регистрация — эти состояния обрабатывались константами класса, что приводило к такому коду:
Почему здесь метод all
? Потому что выпадающий список со всевозможными опциями очень востребован. Для него либо создают такой метод, либо прибегают к использованию отражения.
Но посмотрите, как это упрощается перечислениями:
С ними применяется встроенный метод cases
, в котором автоматически возвращается массив всех доступных опций. Теперь, когда добавляется новый статус, не нужно обновлять список общих параметров вручную.
2) Подсказки типа
Рассмотрим метод для задания статуса пользователя. Сохраняем в базе данных только допустимые статусы:
Выглядит немного уродливо. Но теперь имеется решение получше:
Благодаря подсказке типа, аргумент метода ожидает опцию из перечисления UserStatus
, и мы избавляемся здесь от возможности бага. Проблемы, вызванные недопустимыми значениями статуса, теперь исключены.
3) Методы перечисления
Что, если пользователям с одним статусом разрешено входить в систему, а с другим — нет?
Раньше логика выглядела так:
Теперь же, с перечислением, так:
Разница не большая, но код чище и короче.
4) Уникальность
Хотя этот пункт немного дублирует второй, выделим его отдельно.
К статусам пользователей добавим статусы товаров интернет-магазина:
Возьмем код из примера выше и неправильно его используем:
Ошибки не возникнет. Казалось бы, не такая уж большая проблема, но если мы в будущем изменим значение константы ProductStatus::ACTIVE
, то непременно получим здесь ошибку.
А с перечислениями? Перечисления уникальны.
Даже если у UserStatus::ACTIVE
и ProductStatus::ACTIVE
одинаковое значение, они различаются. Это легко проверить вручную:
Подсказка типа здесь приходится кстати дважды, не позволяя использовать неправильные: значения; источники этих значений, даже если они выглядят подходящими.