Еще один пост о вреде Boolean флагов)
Почему еще один - я за последние пару лет точно видел несколько таких постов)
Но хочется немного обобщить и накинуть практических советов.
В чем суть?
Есть такая рекомендация - вместо нескольких Boolean флагов у одной сущности лучше использовать поле state с Enum типом.
Почему?
Я бы даже поставил вопрос по другому - по каким признаком можно понять, что пора заводить state?
1) есть запрещенные или не имеющие бизнес-смысла комбинации флагов. А число комбинаций растет линейно. Например 3 Boolean поля = 8 комбинаций
2) при установке одного из флагов приходится сбрасывать другие
3) при установке приходится проверять другие флаги
4) флаг X1 был сделан для использования в guard условии специально в модуле Y1. Флаг X2 - в модуле Y2. Но со временем в модуле Y2 приходится проверять оба флага. Это может быть альтернативой для одного из двух предыдущих вариантов.
Видится, что при любой такой проблеме стоит задуматься о добавлении единого state и расписывании переходов между его значениями (state machine).
В идеале - линейной цепочки переходов.
И вообще говоря правило можно обобщить.
Если у сущности есть несколько Boolean или Enum полей, для которых начинают возникать проблемы, описанные выше - это повод к их объединения в один большой Enum.
И Enum тут усугубляет ситуацию: 3 Enum с минимальными 3 значениями у каждого - это уже 27 комбинаций.
Можно даже это паттерном назвать - схлопывание состояний)
#antipatterns #patterns
Почему еще один - я за последние пару лет точно видел несколько таких постов)
Но хочется немного обобщить и накинуть практических советов.
В чем суть?
Есть такая рекомендация - вместо нескольких Boolean флагов у одной сущности лучше использовать поле state с Enum типом.
Почему?
Я бы даже поставил вопрос по другому - по каким признаком можно понять, что пора заводить state?
1) есть запрещенные или не имеющие бизнес-смысла комбинации флагов. А число комбинаций растет линейно. Например 3 Boolean поля = 8 комбинаций
2) при установке одного из флагов приходится сбрасывать другие
3) при установке приходится проверять другие флаги
4) флаг X1 был сделан для использования в guard условии специально в модуле Y1. Флаг X2 - в модуле Y2. Но со временем в модуле Y2 приходится проверять оба флага. Это может быть альтернативой для одного из двух предыдущих вариантов.
Видится, что при любой такой проблеме стоит задуматься о добавлении единого state и расписывании переходов между его значениями (state machine).
В идеале - линейной цепочки переходов.
И вообще говоря правило можно обобщить.
Если у сущности есть несколько Boolean или Enum полей, для которых начинают возникать проблемы, описанные выше - это повод к их объединения в один большой Enum.
И Enum тут усугубляет ситуацию: 3 Enum с минимальными 3 значениями у каждого - это уже 27 комбинаций.
Можно даже это паттерном назвать - схлопывание состояний)
#antipatterns #patterns