DI
ну, она там читает что то, агрегирует и параллелит
Size: a a a
2020 January 07
ED
а теперь вопрос на миллион - а что необходимо для задачи?
Зависит от задачи.
DI
мне всю эту логику вы самому предлагаете написать - или только интерфейс разбить?
G
мне всю эту логику вы самому предлагаете написать - или только интерфейс разбить?
Нет, я предлагаю создать внутренний класс, который вызывает эту функцию, а пользователю предоставить интерфейс из множества классов, которые вместе комбинируются и внутри вызывают эту злосчастную функцию на 30 параметров
G
Я думаю всегда можно просто разделить 30 параметров на 5 параметров-классов из 6 инкапсулированных объектов, самое тупое и простое решение
DI
Я думаю всегда можно просто разделить 30 параметров на 5 параметров-классов из 6 инкапсулированных объектов, самое тупое и простое решение
можно. А чем это поможет?
DI
я не придираюсь, если чо, мне искренне любопытно как люди такие задачи решают...
G
можно. А чем это поможет?
Например, нужно эту функцию на протяжении исполнения программы вызывать много раз. Тогда можно 4 объекта создать и хранить где-то, а пятый всё время конструировать при каждом вызове с другими данными. Выходит много проще, чем вызов функции с 30 параметрами (в вызове которой ошибиться легко, допустим двадцатый и двадцать первый параметры оба int, можно их просто перепутать и компилятор ничего не скажет)
G
А если пять параметров разных типов, то компилятор ошибку кинет, что типы не те
DI
Например, нужно эту функцию на протяжении исполнения программы вызывать много раз. Тогда можно 4 объекта создать и хранить где-то, а пятый всё время конструировать при каждом вызове с другими данными. Выходит много проще, чем вызов функции с 30 параметрами (в вызове которой ошибиться легко, допустим двадцатый и двадцать первый параметры оба int, можно их просто перепутать и компилятор ничего не скажет)
Not bad
DI
ну у нас попроще конечно - параметры все именованные и порядок значения не имеет. Но идея с тем чтобы разделить интерфейс на статическую и динамическую часть мне нра
G
ну у нас попроще конечно - параметры все именованные и порядок значения не имеет. Но идея с тем чтобы разделить интерфейс на статическую и динамическую часть мне нра
Для этого есть ещё хороший паттерн - билдеры. Можно разделить 30 параметров на 5 классов и сделать что-то вроде MyBuilder, который можно так использовать:
MyBuilder::new().address(my_address).message(my_message).send();
А если нужно где-то потом вызвать его, то просто нужно поменять какой-нибудь аргумент и заново отправить:
builder.address(new_address).send();
А все другие аргументы останутся прежними.
MyBuilder::new().address(my_address).message(my_message).send();
А если нужно где-то потом вызвать его, то просто нужно поменять какой-нибудь аргумент и заново отправить:
builder.address(new_address).send();
А все другие аргументы останутся прежними.
G
Можно ещё сделать несколько типов билдеров: готовый к вызову функции и неготовый. Тогда он вместо исключения будет кидать ошибку компиляции, что программист попытался вызвать функцию с не всеми аргументами. Архитектурная от это космонавтика, уже решать, исходя из задачи
G
Вообще ИМХО, типы - самая мощная и самая простая концепция в программировании. Сегодня они даже используются для формальной верификации программ, например пишут сетевой стек на каком-нибудь продвинутом языке и весь стек формально доказан, что не содержит ошибок
DI
Спасибо за совет. Я обмозгую. Вот эти вот многоступенчатые билдеры от меня до этого как то ускользали
DI
Потому что основной аргумент против билдеров у меня всегда был - мы лишаемся статической проверки на то что мы все обязательные параметры предоставили. Вместо этого синтаксический сахар который может в жабе и нужен, потому что параметры передаются по очереди, но нам как то не с руки, потому что параметры и так именованеые
G
Потому что основной аргумент против билдеров у меня всегда был - мы лишаемся статической проверки на то что мы все обязательные параметры предоставили. Вместо этого синтаксический сахар который может в жабе и нужен, потому что параметры передаются по очереди, но нам как то не с руки, потому что параметры и так именованеые
Кстати, обязательные параметры можно передать в
Builder::new(arg1, arg2, arg3), а для опциональных можно сделать методы.G
Тогда билдер всегда будет иметь все обязательные аргументы для вызова функции
M
ну, она там читает что то, агрегирует и параллелит
А проблема в чем? sql тоже вендор лок и ничего есть вполне себе билдеры
M
calcImagProc().Some().Some1().exec()