конструктор, прокидать в него все параметры и в самом конструкторе делать проверки?
или пустой конструктор, создаем объект и потом вызываем какой то метод с той самой логикой и параметрами что были в конструкторе?
голосую за це але послухаю шо умні люди скажуть
мне больше по душе статический метод Create собственно там и валидировать class User { public static User Create(...) { ... } }
а в нем будет new User() который и будет заполняться полями?
типа да, часто встречал что делают протектед конструктор без параметров, а в Create уже все валидирут и строят нужный обьект
окей, еще вопрос, а если параметров которых нужно передать достаточно много (штук 5 к примеру), это нормально? ну в плане не слишком хреново выглядит в коде?
Его еще и асинхроннім при желании можно сделать, в отличии от коснтруктора
хреново выглядит если прям очень много то можно дтошкой прокинуть, но ты уже сам выбираешь - читаемость или следование принципам
можешь аргументировать развернуто?
больше семантической нагрузки в Create чем в new BlaBla
Его еще можно в детелаг засунуть при желании в отличии от конструктора
либо билдер какой-то накрутить если сложный обьект
еще развернутей ) совсем не очевидно что там больше семантики для новичка
какой билдер? можно пример?
https://refactoring.guru/design-patterns/builder
Func<SomeObject> someDelegate = SomeObject.Create;
может глупый вопрос, есть у меня какая то логика по валидации полей, собственно валидирую я все тут. а если мне понадобится изменить какой то поле? придется продублировать эту логику по валидации в отдельный метод или сделать его статическим чтобы можно было использовать в Create?
можно ее держать в приватном методе своего класса, и написать метод какой будет апдейтить твой проп то есть в криейте и апдейте переиспользовать тот же метод
ну приватный метод должен же быть статическим? иначе как я его смогу вызвать в Create?
Обсуждают сегодня