Как еще избежать если … и случаи переключателя

Многие if..else утверждения часто являются признаком того, что Полиморфизм не используется.

Где-то вам нужно будет проверить условия с помощью if-elses, чтобы убедиться, что вы делаете все правильно. Вы можете создать новые подсубпозиции, если не хотите запихивать одну подсубпозицию

Sub AddAnimalManMale()
    If task = 'add' And cat = 'animal' And sec = 'man' And type = 'male' Then
        'perform the add animal man male action'
    End If
End Sub
Sub AddAnimalHorseRun()
    If task = 'add' And cat = 'animal' And sec = 'horse' And type = 'run' Then
        'perform the add animal horse run action'
    End If
End Sub

затем в вашу главную подсубпозицию

...
Call AddAnimalManMale()
Call AddAnimalHorseRun()
...

Если выбор для каждой из этих переменных конечен, вы даже можете использовать такие приемы, как битовые поля с операцией ИЛИ.

Пример:

// give each field a byte so that each can have 256 possible values
#define TASK_ADD 0x01
#define TASK_SUB 0x02
...
#define CAT_ANIMAL 0x01
...
#define SEC_BOY 0x03
#define SEC_MAN 0x04
...
#define TYPE_FEMALE 0x01
#define TYPE_MALE 0x02
...

if ((task << 24 | cat << 16 | sec << 8 | type) == 0x01010402) {
  // do stuff
}

Взлом кода - это все, о чем идет речь в игре.

Исторически так и было бы (и был хороший, или, по крайней мере, стабильный код, и он все еще есть)

• , как вы это делаете сейчас, монолитный с огромными функциями, с множеством комментариев

• разбить его на небольшие, хорошо определенные и хорошо названные функции

• присвоение имен функциям было сложным для сложных вещей, а также, если вы продолжаете передавать ссылки на большие структуры, тогда объекты были естественной вещью для изобретения (однако, как только вы пойдете на объектный путь, то это имеет смысл делать все, и за счет повторного использования кода появляются объектно-ориентированные шаблоны ...)

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

Он называется «Антипаттерн Стрелка». Некоторые из методов борьбы с этим описаны здесь: http://c2.com/cgi/wiki?ArrowAntiPattern

Один из способов, который вы рассматриваете при миграции, - это рефакторинг кода во вложенных уровнях для разделения таких функций, как

if cat = "animal" then
  functionForAnimal();
elseif cat = "plant" then
 functionForPlant();
elseif...


function functionForAnimal() 
  if sec = "man" then
    functionForMan();
  elseif sec = "horse" then
    functionForHorse();
  elseif...

etc...

Это разбивает код на более мелкие фрагменты, которые легче поддерживать и, возможно, использовать повторно.

Предполагая, что вы всегда проводите сравнение на равенство и сравниваете все четыре поля, простой подход, основанный на данных, весьма практичен. Все, что вам нужно сделать, это построить карту из (задача, кот, сек, тип) в функцию для вызова:

handlers = {
    ('add', 'animal', 'man', 'male'): add_man_func,
    ('add', 'animal', 'horse', 'run'): run_horse_func,
    # ...
}

handler = handlers[(task, cat, sec, type)]
handler(some_args)

Полиморфизм может быть полезен, когда у вас разные реализации, но задача концептуально одинакова. Иногда трудно найти естественную структуру классов, и подходы, подобные паттерну состояния или паттерну стратегии , могут быть более подходящими.

Вы описали матрицу с 4 входящими параметрами - задачей, cat, sec, типом и одним исходящим - материалом . Так что вам нужно как-то это закодировать.

Например, карта XML и запрос XPath, например String.Format ("task [@ value = {0}] / cat [@ value = {1}] / sec [@ value = {2}] ] / type [@ value = {3}] "," add "," animal "," man "," male ") , но этот подход указывает на данные, а не на делегат метода.

Другой способ:

void DoStuffA() { }
void DoStuffB() { }

var arr = new[]
{
    new { Task = "Add", Cat = "Animal", Sec = "Man", Type = "Male", Method = (Action)DoStuffA },
    new { Task = "Add", Cat = "Plant", Sec = "Land", Type = "Tree", Method = (Action)DoStuffB },
    // etc..
};

var action = arr.FirstOrDefault(i =>
     i.Task == "Add" &&
     i.Cat == "Animal" &&
     i.Type == "Male").Method;
action();

Также вы можете использовать не анонимные члены, а объявить класс, описать свои варианты в XML и десериализовать их из XML в несколько экземпляров вашего класса.

Я думаю, что в вашем дизайне есть фундаментальные недостатки. Я не знаю, какую проблему вы пытаетесь решить с помощью этого кода, но такой код должен быть очень редким в объектно-ориентированном языке. Ваш код также кажется мне немного нелогичным, потому что, например, тип переменной означает пол при первом использовании (мужской), а затем означает действие (запуск). Вы заметили это?

В любом случае, если вы действительно используете Java (или что-то еще с классами), вам нужна абстракция. Затем перенесите всю возможную логику на свои объекты - не обрабатывайте ее за одну чудовищную рутину. Подумайте так: мои объекты умеют делать свою часть работы.

На самом деле в этой ситуации немного сложно дать хороший совет, я подозреваю, что источник ваших проблем находится на каком-то высоком уровне в вашем приложении, и этот код случая является только симптомом. Попробуйте переделать свою программу, чтобы использовать объектно-ориентированный подход, и, возможно, вам в голову придет лучшее решение.

Если вы не знаете, что означают термины «полиморфизм», «абстракция» и другие объектно-ориентированные термины, вам необходимо прочитать об этом.