Комментарии 63
Как это юнит-тестировать?
Ну, в этом случае юнит-тесты вполне возможны:
- при полиморфизме: тестируем каждый класс отдельно;
- при функциональном стиле: тестируем каждую функцию;
- при использовании шаблонов - тестируем правила по отдельности или их в комбинации.
Плюсом при таком походе будет меньше моков и более чёткие зависимости, более стабильные тесты (нет сложных ветвлений);
А минусом будет то, что надо больше мелких тестов, зато они проще.
А в целом, можно сказать, что тесты станут более простыми и надёжными.
Я намекал на следующую проблему. Принцип инкапсуляции требует, чтобы вся бизнес-логика закладывалась в один класс (не ВООБЩЕ ВСЯ). В частности, это делается, чтобы юнит-тест был цельным, и тестировал бизнес-логику в одном месте. В данной статье предлагается разложить бизнес-логику по нескольким классам - как минимум в класс-фабрику (бизнес-логика здесь - при таком условии выполнить это, при другом условии выполнить это-2), плюс несколько классов с ветками. И все эти классы нужно во-первых, держать в согласованном состоянии, плюс будут базовый класс с разделяемыми данными, во-вторых, нужно тесты держать в согласованном состоянии.
Такой подход хорош, если ветки СОВЕРШЕННО не зависят друг от друга, и можно без проблем выделить их в отдельные классы. Это НУЖНО делать, сплошь и рядом. Но делается это не для того, чтобы "избавиться" от if и case, а для разделения и инкапсуляции алгоритмов (если я правильно применяю термин) и упрощения юнит-тестирования, когда вместо того, чтобы тестировать один класс-монстр, тестировать несколько небольших классов.
Для юнит тестов нет разницы, сделали ли вы через optional или if else они тестируют возвращаемое значение.
Тернарный оператор перестал считаться условным?!
На данный момент боремся с тремя озвученными: if-else, switch :-)
Так это синтаксический сахар к условному.
Тут вся статья буквально про "как спрятать if". Взятие элемента из Map будет сопровождаться кучей проверок, ровно как и функциональный filter, даже если делать дичь как в TS и запекать полиморфизм. то на уровне байткода там все равно окажется какой-нибудь jne. А я то уж понадеялся, что щас про branchless программирование покажут что-нибудь.
Прятали прятали, да только не везде спрятали)
Первая же Фабрика и сразу с if, от которого всеми правдами и не правдами прятались:
пс: прошвырнулся по 40 комментариям, никто и не заметил)
Это - guard clause, он не является частью бизнес-логики, хотя, можно было и без него
return Optional.ofNullable(suppliers.get(type))
.orElseThrow(() -> new IllegalArgumentException(...));
Дипсик рекомендует для мапы кастом писать:
public static <T, R> R mapOrThrow(T value, Function<T, R> mapper, Supplier<? extends RuntimeException> exceptionSupplier) {
if (value == null) {
throw exceptionSupplier.get();
}
return mapper.apply(value);
}
// Использование:
String result = mapOrThrow(optionalValue, String::toUpperCase, () -> new NotFoundException("Not found"));Но вообще надо пошариться на предмет наличия готовых классов фабрик, чем велосипед писать.
На зло маме отморожу уши. А зачем? Читабельность никакая, ресурсов тратит больше.
Здесь больше речь о возможностях как таковых. А как их использовать и использовать ли - второй вопрос ;-)
В примере с оптионал вполне повышает читабельность. Возьмите пример простого кода, добавьте в него все пропущенные проверки на нул и сравните. Последовательные операции намного легче читать, чес скакать по дереву условий.
Без условных операторов, серьёзно? Я в этом коде вижу как минимум три условия: isValid, isCurrentDayData(), orElse().
выбор конкретной реализации может быть передан «фабрике» — что избавляет нас от необходимости реализации проверок в основном коде.
Дженерики использовать не судьба? Паттерн матчинг, в конце концов?
Зачем вообще всё это? Отказ от if/switch – это религия какая-то? В некоторых случаях это действительно приводит к трудночитаемому коду, но приведённые примеры к таковым не относятся.
P.S. Использование скриншотов вместо вставок кода – плохая практика, затрудняет цитирование.
Напишите как вы видите более лучшую реализацию для конкретно этого случая, мы с удовольствием ознакомимся с вашим предложенным подходом ;-)
P.S. Без всяких подколов - реально интересно. "Век живи- век учись".
Напишите как вы видите более лучшую реализацию для конкретно этого случая
Я для всех случаев вижу, что каждое средство языка должно использоваться на своём месте, и не должно быть никаких религиозных догм типа полного отказа от if/switch – это приводит к ненужному усложнению кода.
Без условных операторов, серьёзно? Я в этом коде вижу как минимум три условия:
isValid,isCurrentDayData(),orElse().
Только это методы, а не операторы.
Во первых, нет: там тернарный оператор, который есть просто альтернативная форма записи if/then/else. Во-вторых, такое упрятывание условных ветвлений не улучшает, а ухудшает читаемость кода.
Что мы здесь видим: существует карта
Map, заполненная ключами (например,source_1) и значениями, где в качестве значений выступают конструкторы соответствующих классов.
Стоит добавить, что такой подход неплохо показывает себя в продакшене, где есть множественные реализации чего-либо вкупе с каким-нибудь DI-контейнером (тот же Spring). Только вместо строковых литералов безопаснее использовать enum.
Есть ощущение, что все это "концептуальность ради концептуальности".
В реальной жизни постоянно приходится сталкиваться с достаточно сложными условиями - "если А лежит в диапазоне от ... до ..., при этом Б меньше чем ... и С больше чем...". Пытаться все это сделать без if? Ну, наверное, можно. Но получится многословно и неочевидно - если вам достанется на доработку такой чужой код, то понять что именно он делает будет сложновато - вам придется все эти уровни абстракций копать до самого дна - "а вот этот isValid - он вообще как валидирует? А мне по новым условиям нужно чтобы оно иначе валидировало - куда лезть и годе править?"
Ну и есть стойкое ощущение что все условные операторы просто прячут куда-то вглубь абстракций и внешних зависимостей чтобы потом гордо сказать "я не пользуюсь if" (при этом забывая сказать что "я пользуюсь тем, что пользуется if").
Функциональное программирование представляет собой такой подход, при котором программа строится только на использовании функций, которые передаются как аргументы, возвращаются из других функций
А где та самая первая функция, которая не вызывает других функций, а делает все сама? Является ли она частью функциональной парадигмы, или это процедурность, лежащая фундаменте всего остального?
Ну тут спорно, сложные конструкции из вложенных ифов понимать сложнее, чем несколько абстракции. Другое дело, что баланс нужно соблюдать и не наворачивать абстракции, если условия плюс-минус простые.
Сложные конструкции вообще сложно понимать :-) Абстракции плохи тем, что когда нужно понять логику работы программы (а в жизни неоднократно приходилось сталкиваться с весьма и весьма мудреной и неочевидной бизнеслогикой), приходится работать одновременно с несколькими исходниками, отслеживая каждый вызов "до самого дна".
А уж когда нужна аналитика типа "кто использует этот модуль" (на предмет оценки рисков и объема регресс-тестов при его изменении), а там начинается - этот модуль используется модулем А, который вызывается из модуля Б, а тот задействован в модуле В...
Но не суть.
Простота чтения кода - это не про использование или не использование if. Это про стиль. Многовложенные if, конечно ничуть не проще в понимании чем пирамида многоуровневых абстракций... Так что тут стоит использовать все средства, которые могут облегчить читаемость кода.
Смотрю на зоголовок:
"Программирование без условных операторов"
Смотрю в статью, там условный оператор.
Штош.....
Статья о том как уменьшить читаемость и спрятать/замаскировать условные операторы
При фразе "программирование без условных операторов" ожидал увидеть статью про информационную безопасность, и защищённые от взлома алгоритмы, где неиспользование условных переходов усложняет исследование.
А получил "спрячем все ифы в метод IfElse и назовём это функциональным стилем".
Наименее разочаровывает пример про полиморфизм, хоть и обфусцирует исходный алгоритм.
Избавиться от условий.. чтобы что? Ради академического интереса - ладно. Ради быстродействия? Нет. Идея для следующего опыта - исследовать smali различных подходов. Там видно будет во что (в какие инструкции) превращается иф, елс и свитч. Сам, как писатель на джавах, могу сказать что этот язык запросто может избаловать и превратить простой проект в вавилонскую башню. Особенно заметно по ждунам, которые начинаются модных авторов и начинают изобретать собственные архитектуры. Могу посоветовать параллельно изучать другой, более низкоуровневый язык. Это помогает "размылить" взгляд и начать думать логически, а не обмазываться фабриками и полиморфизми. Можно Си, причем лучше под микроконтроллеры (хоть есп, хоть ардуины), они научат в сложных моментах экономить такты процессора и оперативную память.
Как программист графики, с большим интересом ткнул на статью.
В видеокартах ветвление усложняет выполнение задачи - рабочие треды ядра заканчивают одну ветвь, и только потом приступают к другой. Причëм это не распараллеливается. Так что для крипты/игр/ИИ задача более чем актуальная.
Подумал, будут хитроумные трюки с битмасками, адресами памяти и побитной логикой.
Нашëл какую-то джавную ООП ересь, теперь глаза с мылом придëтся мыть
У статьи неправильное название, правильное название что то вроде - как писать на фп.
От условных операторов вы толком и не избавились. Абстракции функциями все так же используют условный оператор под капотом, вы лишь сделали их невидимыми. Кроме как повысить читаемость (даже тут спорно, повышает ли) и научного интереса, вы ничего не достигли и у в реальной жизни такой код писать никто не будет. Ракеты вы на этом не построите, ядра ос тоже нет, лёгкую прошивку железа тоже будет сложно.
Объяснение абстрактных фабрик и полимоофма и у вас вышло лучше, чем вся статья. В остальном - сомнительно.
в реальной жизни такой код писать никто не будет. Ракеты вы на этом не построите, ядра ос тоже нет, лёгкую прошивку железа тоже будет слсложно
Да нормальный код. Понятно, что примеры упрощенные, но такой подход широко применяется. Не все строят ракеты и пишут для встраиваемых систем. Для энтерпрайза такие вещи вполне обыденные.
Конечно, никто не отказывается от условных операторов, но иногда подобные замены сильно повышают читабельность и расширяемость. Делать фабрику с десятками case - такое себе решение, а с мапой уже выглядит получше.
Использование Optional тоже хорошая штука, когда нужно сделать цепочку проверок и преобразований или вернуть результат, над которым можно сразу произвести такую цепочку без явных ветвлений.
Насколько я понял, в основном претензии к автору за громкий заголовок, хотя, если его рассматривать, как фигуру речи, описанные подходы вполне обычные и широко распространены
Сам люблю ФП в Java, но автора донедопонял. Ifы, свичи - это исчисление предикатов, как без них реализовывать фундамент ФП как гарды и паттерн матчинг я не понимаю. Кроме того "сохранение функции в переменной" выходит за рамки ФП, это скорее особенность Явы, которая делает ее гибридной. В чистом ФП переменных нет
кажется, что читаемость не повышена. Меня лично вполне устроил бы switch с тремя предсказуемыми вариантами, а не интерфейс с фабрикой.
Почему фабрика не сделана статическим классом?
Ифэлсефобия в тяжёлой форме )
вот бред
Map конечно хорошо, но достаточно было обычного массива с enum для индексов. Все таки внутри реализации map if-ов будет предостаточно. Это как спрятать их внутри другой функции (тоже самое и с полиморфизмом). + в кеш проца легло бы отлично
а вы switch используете, и насколько часто?
эээ, а как же тогда описывать конечные автоматы состояний без switch?
По заголовку сначала подумал, что речь пойдет про branchless программирование
Не знаю точно как рантайм джава с этим работает, но что-то мне подсказывает, что помимо ухудшения читабельности появляются еще накладные расходы. И всё ради того, чтобы спрятать if. Гениально.
Естественно. Если вместо простого if поставить вызов какой-то функции (с разворачиванием-сворачиванием стека, а еще, не дай бог, выбросом исключения), а потом вызвать все это 100500 раз, разница в производительности будет заметна. Но кого все это волнует? Главное же концептуальность. А если у потребителя все это начинает тормозить - пусть заменит один старый сервер на два новых, помощнее и подороже.
Зато когда MS заявляет что поддержка Win10 заканчивается, а для перехода на Win11 потребуется обновить комп, нас это дико возмущает - да как они посмели...
условные операторы, такие как If, else, switch — и особенно часто их используют новички, потому что их понимание и работа достаточно проста
многие отмечают, что последний оператор switch им приходилось видеть только на разнообразных олимпиадных задачках или школьных уроках
(а вы его используете, и насколько часто?).
Тем не менее, как бы там ни было, существует целый ряд иных подходов, который позволяет избавиться от этих операторов
можно отметить, что не нужно забывать главное — избавление от условных операторов не является самоцелью программирования
И к слову — как вы поступаете, чтобы уйти от ef-else?
Статья кажется провокацией с идеей, что "if и switch - это (почти) новый goto". Потому что в ней избегается вопрос: "в какой момент решение на if'ах становится лапшой и перестаёт справляться со сложностью". Без этого вопроса телега оказывается впереди лошади: решение есть, а проблемы нет.
Это так плохо, что даже хорошо.
Сейчас предложу вашему вниманию реализацию на JavaScript:
let logicController = [()=>log('если нет'), ()=> log('если да')];
logicController[~~condition]()Для продакшен грейд прятанья ифа стоит пойти на шаг дальше и реализовать фабрику
export class LogicFactory {
constructor(accept, deny){
this.destinations = [deny, accept];
}
proceed(destination){
return this.destinations[~~destination]();
}
}Usage example:
const possibilities = new LogicFactory(
()=>`we should chop the tree`,
()=>`let beavers do the job`
);
let totalTreesInTheWoodsAmount = prompt('How many trees do you see right now?');
console.log(possibilities.proceed( totalTreesInTheWoodsAmount > 10 ));Теперь мы можем написать алгоритм любой сложности без явного использования богомерзкого ветвления.
Вообще не понял для чего эта статья и для чего это нужно. Избавиться от if/else на 3-5 строк, чтобы нагородить несколько объектов, интерфейсов, обмазаться optional, а впродакшен коде там тысячи ветвлений, это в простом коде тогда будут тысячи классов пустышек и интерфейсов. Как я часто пишу - страшное в таких статьях то, что джуны сейчас пойдут такое продвигать и использовать, и вот такое нельзя допускать.
Если делать такое чисто по фану, то нужен отдельный раздел на хабре для таких приколов.
Если делать такое чисто по фану, то нужен отдельный раздел на хабре для таких приколов.
Он есть, хаб "Ненормальное программирование".
Про switch что-то ничего не увидел...
А вообще это очень удобная штука для создания пошаговых действий и визуально все наглядно, особенно если сопровождается комментарием перед каждым блоком... Переделывать во что-то другое смысла ноль.
Спасибо за статью
мне лично стали понятны многие "приколы" в нашем коде.
Программирование без условных операторов