Без-программирование (в основном без условностей)

Ответ 1

На сайте Anti-IF Campaign есть несколько ресурсов, например этой статьи.

Я считаю, что это вопрос степени. Условности не всегда плохие, но они могут (и часто) подвергаться насилию.

Дополнительные мысли (на следующий день)

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

Я оцениваю простоту и единоличную ответственность за удаление всех операторов if. Эти три цели часто совпадают. Инструменты статического анализа, которые поддерживают циклическую сложность, могут быстро указывать код с вложенными или последовательными условными обозначениями. Операторы if могут оставаться после рефакторинга, но могут быть разбиты на более мелкие методы и/или несколько классов.

Обновление: Майкл Перс написал статью о Безусловное программирование.

Это популярная тема: Фил Хаак на Смерть для оператора IF!

Ответ 2

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

Там хорошо говорят Санди Мец, где она реорганизует действительно волосатый шар if-заявлений на что-то waaay менее волосатое: https://www.youtube.com/watch?v=8bZh5LMaSmE

Ответ 3

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

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

Есть что сказать: разрастание утверждений if внутри ООП может быть симптомом плохого программирования. Пример:

Не используйте, если нужно проверить возвращаемое значение функции как старое программирование в стиле C:

int ret = some_func();
if (ret != null)
   //do something

Это было типично для кода C, но с ООП вы должны использовать исключение:

try{
    do_something();
}catch(Exception e){
    e.printStackTrace(); //why I was not able to do something
    handle(e); //there is something else I could do to handle the occurred error
}

Иногда, если утверждения распространяются на плохой дизайн. Рассмотрим следующий пример в Java:

BaseClass base;
if (base instanceof DerivedClassOneFromBase){
    DerivedClassOneFromBase d = (DerivedClassOneFromBase)base;
    d.methodOne();
}else if (base instanceof DerivedClassOneFromBase){
    DerivedClassTwoFromBase d = (DerivedClassTwoFromBase)base;
    d.methodTwo();
}

Это еще один пример неудачных утверждений, вероятно, связанных с плохим дизайном. Если у двух производных объектов будет общий метод, определенный в базовом классе BaseClass, вы могли бы вызвать этот метод вместо проверки их конкретного типа и их литья:

base.commonMethod();

Ответ 4

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

Ответ 5

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

Если у вас есть класс под названием Automobile и подклассы, такие как Car and Bike, и метод, например:

drive(Automobile a)
   if (a.isCar)
      // do stuff
   else if (a.isBike)
      // do stuff

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

Например:

save(Car c)
   if (c is new)
      // do some stuff
   else if (c is old)
      // do some stuff

потенциально может быть разбит на сохранение и обновление, поскольку это две разные функции. Хотя это и зависит.

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

Ответ 6

Избегание условностей не обязательно означает, что вам нужно сделать это путем полиморфизма или наследования, возьмите, например:

У вас есть 3 разных папки для хранения загруженных изображений, загруженных видео и загрузки pdf

Вы можете написать код как:

uploadMedia(mediaType){
   if(mediaType == images){
     uploadTo("myProject/images");
   }else if(mediaType == videos){
     upoloadTo("myProject/videos);  
   }else if(mediaType == pdf){
     uploadTo("myProject/pdf");
  }
}

Другой альтернативой, которую могут использовать люди, является случай переключения:

uploadMedia(mediaType){
         switch(mediaType){
         case : images
         uploadTo("myProject/images");
         break;

         case : videos
         uploadTo("myProject/videos");
         break;

         case : pdf
         uploadTo("myProject/pdf");
         break;
    }
}

Но тогда вы можете полностью избежать условного утверждения, используя что-то вроде словаря /hashmap/json (в зависимости от того, с чем вы работаете):

Например:

HashMap<String,String> mediaMap = new HashMap<>();

mediaMap.put("images","myProject/images");
mediaMap.put("videos","myProject/videos");
mediaMap.put("pdf","myProject/pdf");

//mediaType can be images/videos/pdf same as keys of mediaMap
uploadMedia(mediaType){
  uploadTo(mediaMap.get(mediaType));
}

Это своего рода псевдокод, поэтому возможны синтаксические ошибки, но в целом эта концепция также полезна для предотвращения условностей. Также можно уменьшить строку кода.