Большое количество флагов при инициализации приложения?

Есть вэб приложение, которое собирает себя по кусочкам и в зависимости от передаваемого на старте конфига. При этом может произойти все что угодно, поэтому в целях обеспечения стабильности по всему коду разбросаны куски с кодом типа if (configLoadedFlag == true && frameworkLoadedFlag == true) {} else {} и естественно падение с логированием в критичных случаях. Хотелось-бы уменьшить количество ветвлений / упорядочить флаги. Помнится что-то из пэттэрнов было на этот счет.
  • Вопрос задан
  • 2431 просмотр
Пригласить эксперта
Ответы на вопрос 5
Спрячьте все флаги, которые «размазаны» по коду, внутри отдельного класса, который в зависимости от их состояния генерирует (шаблоны Factory и Strategy) объекты, выполняющие нужные функции. Это сократит количество ветвлений и снизит связность кода.
Ответ написан
zizop
@zizop
Насколько я знаю, есть паттерн стратегия для избегания кучи if-ов. Но я не уверен, что он подойдёт вам, т.к. по идее с ним надо работать с конфигурацией (совокупности флагов в данном случае). А то, что у вас if-ы разбросаны по всему коду — повышает его связанность. Раз вы говорите, что у вас много «кусочков», которые друг от друга зависят, может быть вам использовать Dependency Injection?
Ответ написан
VenomBlood
@VenomBlood
А проверки данных флагов как-то связаны?
Например может ли configLoadedFlag && frameworkLoadedFlag означать что-то целостное? В таком случае хорошо будет инкапсулировать просто логику проверки в один класс, возможно проверять значение Flagged enum. Если же различных комбинаций примерно комбинаторное количество (и они не связаны описанным образом) — это не подойдет.
Ответ написан
VenomBlood
@VenomBlood
Если для каждого взведенного флага выполняется свой более-менее независимый комплект операций — действительно как описали выше — лучше выделить интерфейс работы с этой «конфигурацией», и при помощи регистрации сопоставлений действие-флаг реализовать необходимую логику.
Тут и IoC как раз можно будет воспользоваться.
Ответ написан
fzn7
@fzn7 Автор вопроса
Внутри уже реализован набор комманд. Все они выполняются последовательно если все идет хорошо, однако мы не в идеальном мире и что-то постоянно падает. Возможно сервер не отдал конфиг, возможно конфиг оказался невалидным, возможно сервер с кодом внешних библиотек отвалился. В итоге мы 3 раза перезапрашиваем конфиг или в зависимости от ошибки пытаемся попросить библиотеки из другого места итд итп. Если рассматривать configLoadedFlag && frameworkLoadedFlag то да это целостное. Это значит что мы загрузили все необходимое и моно стартовать само приложение. Если что-то из 2х еще в процессе, то нужно ждать. Соответственно сюда может добавиться еще какой-то флажок типа socketConnectionReadyFlag.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы