параметр и их количество? Или сделать одну громоздкую и внутри определять, что делать с параметрами?
по опыту, лучше первый вариант )) Опять же, в пределах разумного )
Есть кейсы, где это избавляло от проблем?
если функции, действительно, отличаются только типом параметра на входе - их надо сделать генериками, или кодогенерацией, если генерики не справятся
тесты класть боль
второй варик читаемость убьет и тестировать заебешься
Верхнеуровнево: на мой взгляд, это имеет смылсл, если ты не боришься за проценты эффективности. Функции(методы), структуры, интерфейсы - абстракции, а они не бесплатно Почему мне нравятся больше функции с ограниченным числом параметров: потому что таким образом ты ограничиваешь минимальный необходимы скоуп и раскладываешь свою логику по слоям, что обычно положительно сказывается на: читаемости, тестирование НО если тот же самый код можно написать с помощью дженериков, то я б писал одну функцию на дженериках
Да, есть, обычно это бьёт в: «Я что-то хочу поменять в функции, но хз что отвалится если я один параметр подкручу» - нарушение SRP
Мб зайдёт паттерн «Template method»
а как его на го сделать?
Также как и на другом языке
ЭЭЭЭ, ты меня даже в ступор ввёл
на другом языке без наследования?
Да, это ж не делает это невозможным его использовать в ограниченном наборе кейсов
Google -> template method golang
можно пример шаблонного метода на го? Я бы просто посмотрел
поиск заходил дальше сайта рефакторинг гуру?
А это чё за сайт
Мне стэкоферфлоу хватает обычно
Обсуждают сегодня