Комментарии 20
Большой список аргументов конструктора "звоночек" для проведения рефакторинга. К тому уже есть Паттерн позволяющий передавать большое количество аргументов: объект-параметр. В предлагаемом решении сложно определить какие параметры обязательно должны быть инициализированы, надо будет или компилировать каждый раз сборку или лезть в исходник и смотреть какие свойства помечены required
Компилятор будет ругаться если не все проинициализировать.
Кажется, что объект-параметр тоже будет не акруален, по крайней мере не везде.
"звоночек" да, но когда цена рефакторина выше пользы, звоночек можно замьютать)
В том то и дело пока я не соберу код я не всегда смогу узнать какие свойства забыл инициализировать. А если все эти свойства "размазаны" по иерархии наследования то это может превратиться в нехилый квест. :) Я пользуюсь простым правилом как только количество аргументов становится больше 5 я или упаковываю их в объект параметр или делаю декомпозицию. Да и с большим количеством аргументов у меня получается не сильно много от силы 5-10% от всего кода, так что можно и по старинке через конструкторы :)
Ну то есть при прочих равных, как и с большим конструктором, мы просто будем иметь большой список инициализатора.
Из плюсов - только не переопределять эти параметры у наследника
Из минусов - контракт создания класса не ясен, тебе подсказывает, что класс простой, но на самом деле его просто так не проинициализировать.
Или строитель можно использовать, топовый паттерн)
Проблема контруктора с большим количеством аргументов не решается объектом-пареметром. Просто она меняется на проблему инициализации объекта-параметра. И его придется инициализировать через конструктор с тем же количеством аргементов либо через свойства и ловить ошибки неполной инициализации в рантайме.
Тут была озвучена проблема передачи большойго количества аргументов по иерархии наследования. Данную проблему объект-параметр решит. Можно в конструкторе объектов параметра проводить нужную валидацию и не допускать неполную инициализацию. Ну я уже писал выше, что не нужно решать саму проблему, а нужно устранять причину. Большего количество аргументов а конструкторе повод провести рефакторинг или пересмотреть архитектуру.
Ещё можно сделать source generator, который за вас будет писать конструкторы. Это не теория, я за пару дней справился (без поддержки наследования, но это у нас нужно редко).
github.com/blowin/Blowin.Required
очень жду, мне очень не хватало этой прелести. Из моих хотелок остались пропосы на:
1) анонимные деконструкторы типов (в том числе и в ограничениях обобщенных методах)
2) наследование энамок
Надеюсь протолкну их как можно скорей , в отличии от required )))
А если надо private поле инициализировать через конструктор? Лучше б primary constructor сделали. А вообще наследование - зло.
Одна из альтернатив -- использовать Import\Export атрибуты. Правда это скорее всего только для случая "нужно проинициализировать 100500 полей, проект простой, а мне лень".
В данных примерах напрашивается внедрение зависимостей и ioc-контейнер. А как именно фабрика будет собирать обьекты нет так важно.
А множество аргументов и наследование -зло
Не понимаю почему readonly поля нельзя разрешить задавать в инициализаторе.
Лучше посмотрите asp net core. Как в конструктор сервисов попадают другие сервисы. И особенно что происходит когда сервисы ссылаются на друг друга в одинаковом scope.
Все еще жду, когда появятся фичи из f# с темплейтами, но видимо не дождусь никогда, поэтому проблему раздутых конструкторов в энтерпрайзе без "Охоспаде какого здесь функция" пока не решить в полной мере :с
C#: required