Как избавиться от многочисленных if/else?

Question

[ddd329]

Доброго времени суток!

Имеется примерно такой псевдокод для неких расчетов:

IF Условие 1 THEN
    Делаем расчеты первым методом
ELSE IF Условие 2 THEN
    Делаем расчеты вторым методом
ELSE IF Условие 3 THEN
    Делаем расчеты третьим методом
ELSE
    Здесь обращаемся к базе данных и находим последнее валидное значение
END

Суть в том, что необходимо сделать расчеты. Выберем для этого первый метод, если не получилось первым, то нужно попробовать вторым, иначе попробовать третьим, но в случае, если все методы не принесли успешных результатов, то необходимо обратиться к Базе Данных и там найти последнее успешное значение.

Таких вот if/else по коду может около 20, причем тут идет смешение разной логики: бизнес-логики и логики обращения к БД.

Знаете ли вы как можно "красиво" организовать подобный код? Может какие-нибудь паттерны проектирования можно применить?

Comments

[Дмитрий]

Почитайте про solid

[ddd329]

Дмитрий, так в том-то и дело, что такой код нарушает эти принципы.

[Дмитрий]

ddd329, ну это тоже явно, у вас много ответственности, надо пересмотреть архитектуру

[ddd329]

Дмитрий, а по делу?

[Дмитрий]

ddd329, вы дали пример кода, вам дали ответы, по какому делу?

[ddd329]

Дмитрий,

ну это тоже явно, у вас много ответственности, надо пересмотреть архитектуру

Как разделить ответственность?

Если разбить код на методы, то они все равно будут принадлежать одному классу, т.е. все равно ответственность за бизнес-логику и за логику обращения к базе данных будет "висеть" на одном классе..
Понимаешь?))

[Дмитрий]

ddd329, без кода не понятно как разбить, можно как минимум базу данных отделить, не понятны условия, методы, аргументы, данные

Answer 1

[Adamos]

class CalculationData;

abstract class Calculation 
{
  public function calculate(CalculationData data);
}

class CalculationQueue 
{
  public function addCalculation(Calculation calculationVariant, int priority);

  public function calculate(CalculationData data) {     
     for (c in calculations) {
       if(res = c.calculate(data)) return res;
     }
  }
}

Comments

[ddd329]

Adamos, Действительно, хорошее решение!
Спасибо!

[lJser]

ddd329, плохое решение

[Adamos]

lJser, аргументы?

[ddd329]

lJser,

плохое решение

плохой аргумент.

Да вы в принципе по существу ничего и не сказали. Вот ваши ответы касаемо данного вопроса:

всё зависит от того, как устроены условия и выполняемые действия.
Без этой конкретики ответа быть не может, кроме очевидного switch

Практически на любой вопрос можно ответить так: что все зависит от условий. То, что вы предлагаете заменить if/else на switch ничего не меняет. А если мне надо было заменить swicth, вы бы мне if/else предложили? А почему не тренарный оператор "условие ? действие 1 : действие 2"?

Не зная деталей это может быть плохим решением.
P.S. код, кстати, нерабочий

Ну вообще-то, как мне показалось это просто псевдокод... Неужто вы его скопировали и попытались скомпилировать и запустить??

Теперь почему идея этого кода хороша. Скорее всего Adamos показал идею реализации паттерна "цепочка обязанностей", но не суть... При таком подходе код можно разбить на маленькие классы Calculation, которые будут выполнять ровно одну задачу и не более. Каждый такой класс будет иметь свои зависимости, и только те, которые нужны ему для выполнения своей мини-задачи. Также реализации этих классов могут относиться к разным слоям приложения, один будет реализован в бизнес слое, другой в инфраструктурном и т.д. Также соблюдается принцип открытости/закрытости, для добавления нового поведения, вам необходимо написать нового наследника от класса Calculation.

Подводя итоги, скажу что идея очень хороша! Если существует более лучшее решение, то прошу его нам показать! Лично мне очень интересно увидеть ваш код.

Answer 2

[antonwx]

Очевидный switch. Есть в большинстве языков.

Comments

[ddd329]

antonwx, дизлайк однозначно ...

[antonwx]

ddd329, ну не нравится - не пользуйтесь, никто не заставляет

[Дмитрий]

ddd329, это очевидно же, почему дизлайк?

[Дмитрий]

ddd329, https://www.sonarsource.com/docs/CognitiveComplexi...

[ddd329]

Дмитрий, почему дизлайк? Да потому что логика та же получается что и с if/else.

[Дмитрий]

ddd329, для вашего куска псевдокода это как раз решение, либо разносите логику, делите и сокращайте, логика сильно большая в одном месте

[Дмитрий]

ddd329, возможно стоит подумать над уменьшением количества аргументов для методов, и все без условий решится

[ddd329]

Дмитрий,

для вашего куска псевдокода это как раз решение, либо разносите логику, делите и сокращайте, логика сильно большая в одном месте

Так я и спрашиваю, как можно разнести эту логику, поэтому про паттерны и спросил.
А то, что if поменять на switch ничего не поменяет. Те же куски кода, с той же логикой, в том же методе...
Вы разве этого не понимаете??

[Дмитрий]

ddd329, ну вы дайте не псевдокод, а так мы просто тратим время

[antonwx]

ddd329, вам надо проверять условия и в зависимости от них выполнять код. Что вы придумаете кроме if-ов и switch-ей? И надо ли вообще придумывать? Нет, можно создать что-то типа именованного массива методов, например:

(псевдокод)
array['method1'] = function(){ ... }
array['method2'] = function(){ ... }
array['method3'] = function(){ ... }

и потом вызывать обработчик вот так:
array[value]();
если, конечно, подобное поддерживает язык.
Но:
1) в отличие от ифов и свитчей, реализация подобного мазохизма сильно разнится в языках
2) это делает код намного более сложным и менее понимаемым для стороннего специалиста

[ddd329]

antonwx, интересно, а я если бы я спросил, чем можно заменить монстрообразный switch, вы бы мне конструкцию if/else посоветовали?

[antonwx]

ddd329, да, посоветовал бы. Вся эта ситуация напоминает примерно такую:
- Здравствуйте ребята, я хочу поставить себе в дом окно, но я не хочу в нём стекло, посоветуйте альтернативу стеклу
- Ставь пластик вместо стекла
- Неее, не хочу пластик, он тоже прозрачный, да и не видно со стороны, что это не стекло
и в итоге решение получается примерно уровня "Влепить на всё окно LCD-панель и выводить на неё изображение с камеры, размещённой снаружи".

[ddd329]

antonwx, спасибо! Поднял настроение)))

Answer 3

[Сергей Горностаев]

Обычно пелёнка условных выражений (особенно многоуровневая) является сигналом о возможности использовать паттерн состояние. Так же полезно выполнить декомпозицию кода принимающего решения и кода выполняющего вычисления, то есть возвращать не результат вычислений, а выполняющее их поведение. Совсем хорошо, если завернуть его в maybe-тип, чтобы вызывающий код мог делегировать получение значения по умолчанию другому коду.

Comments

[Антон Р.]

А если так: https://refactoring.guru/ru/replace-conditional-wi...
?

[ddd329]

Антон Р., такой прием используется, когда объект при создании имеет какой-то определенный тип и на протяжении своей жизни его не меняет, а если меняет, то тогда надо использовать паттерн "состояние". Где-то у Фаулера об этом было написано...

[Сергей Горностаев]

Антон Р., зависит от ситуации, как и с любыми другими паттернами. Если в архитектуре есть место, куда естественным образом встанет фабрика, то вполне хорошее решение. Но в случае сферического проекта в вакууме, это просто замена switch'а возвращающего значение скорости на switch порождающий объект, возвращающий скорость.

Answer 4

[Rsa97]

Выберем для этого первый метод, если не получилось первым, то нужно попробовать вторым, иначе попробовать третьим, но в случае, если все методы не принесли успешных результатов, то необходимо обратиться к Базе Данных и там найти последнее успешное значение.

Ваш код не соответствует этому описанию. В приведённой цепочке if-else выполнение какого-либо метода зависит не от результата предыдущего метода, а от набора неких внешних условий. Для цепочки можно использовать

result = tryMethod1() || tryMethod2() || ... || getFromDB();

Comments

[ddd329]

Rsa97,

Ваш код не соответствует этому описанию.

Согласен, наверное следует больше ориентироваться на описание.
Псевдокодом я хотел продемонстрировать множество if/else, наверняка у каждого программиста такое встречается, и кто даже гордится таким кодом, мол смотри какая у меня сложная логика...

[antonwx]

ddd329, вот только зачем изобретать велосипед? Всё работает, всё логично и понятно, лучше потратить время на разработку новых функций, доработку и оптимизацию старых, чем на изобретение велосипеда.

[ddd329]

antonwx, в чем-то вы правы, но я бы не хотел смешивать бизнес-логику и логику доступа к базам данных. Такая логика должна находиться на разных уровнях - уровень бизнес-логики и инфраструктурный уровень.
К тому, если писать модульный тест, то необходимо абстрагироваться от любого внешнего источника (в данном случае БД)

Answer 5

[lJser]

всё зависит от того, как устроены условия и выполняемые действия.
Без этой конкретики ответа быть не может, кроме очевидного switch

Comments

[ddd329]

lJser, вот же человек дал ответ

[lJser]

ddd329, так себе ответ. Не зная деталей это может быть плохим решением.
P.S. код, кстати, нерабочий

[ddd329]

lJser, да тут не столько сам код, а смысл его.
Очень жаль что вы его не видите...

[Antonio Solo]

ddd329, а в чем "смысл"? в полном переборе ? так себе "смысл", скажу я вам.

обернуть полный перебор в классы ... а зачем ? тем более вот с этим явным добавлением

public function addCalculation(Calculation calculationVariant, int priority);

выглядит как-то не очень красиво.

[ddd329]

Antonio Solo, пусть будет по вашему...

[Adamos]

Antonio Solo, смысл не в "полном переборе", а в выполнении расчетов в порядке, заданном приоритетом при добавлении, до тех пор, пока расчет не будет удачным. То же самое, что у ТС в оригинале, но универсально и без спагетти.
Явное добавление позволяет использовать код в нескольких местах, где список расчетов разный, без дублирования кода.
В общем, это ООП, чтобы его распробовать, нужно время и опыт.

[ddd329]

Antonio Solo, например, для классов уровня бизнес-логики приоритет выше, а у классов для работы с базой данных уровень можно задать пониже.
Вообщем подход гибкий и простой по своей сути. В этом его и красота.

Answer 6

[Antonio Solo]

тут смотря что за условия

если условие сравнение с константой, и таких условий много я бы использовал словарь (ассоциативный массив) в значениях которого были бы указатели на функцию

если же условия сами по себе являются какими-то вычислениям, то тут конечно без перебора не обойтись.