Здравствуйте, Codealot, Вы писали:
C>В чем неудобства, собственно говоря? Тоже хочешь экономить классы?
В том, что писал класс A, а нужно создавать объект хз какого класса с хз каким названием.
Потом это всё в логах где-то будет маячить, в отладчике хз как с навигацией выйдет.
sealed класс не сделаешь.
Иногда бывает хочется закрыть конструкторы и выставить наружу фабричные методы, опять в пролёте.
Да и просто получается генератор должен не только метод собрать, но и продублировать все конструкторы, чтобы они base вызывали.
При наследовании получается нужно перебирать всю иерархию классов на предмет таких виртуальных методов,
чтобы генератор для всех наследников метод продублировал в его персонального наследника (если конечно в этом классе вручную никто метод не перегрузил и не реализовал).
Либо нужно будет самому везде наследоваться от сгенерированного класса, а не того, что сам писал,
а значит в уже существующую иерархию собрался добавить генерируемый метод — сиди все наследования переделывай, а это ещё может быть и в разных проектах.
А если в одном классе 2 разных генератора должны собрать по 2 метода, то сколько наследников будет?
Сначала один генератор своего наследника сделает с копиями конструкторов и двумя сгенерированными методами, а потом второй ещё одного наследника будет создавать?
Не видно ни одного преимущества такого варианта, как не видно и ни одного недостатка у варианта с partial.
Здравствуйте, karbofos42, Вы писали:
K>В том, что писал класс A, а нужно создавать объект хз какого класса с хз каким названием. K>Потом это всё в логах где-то будет маячить, в отладчике хз как с навигацией выйдет.
Тебе самому не смешно?
K>sealed класс не сделаешь.
С чего вдруг?
K>Иногда бывает хочется закрыть конструкторы и выставить наружу фабричные методы, опять в пролёте. K>Да и просто получается генератор должен не только метод собрать, но и продублировать все конструкторы, чтобы они base вызывали.
Ты сам себе противоречишь. Или одно, или другое.
K>Сначала один генератор своего наследника сделает с копиями конструкторов и двумя сгенерированными методами, а потом второй ещё одного наследника будет создавать?
Естественно, не нужно этого делать. Один наследник для всего сгенеренного кода.
Ладно, пара пойнтов у тебя есть. Но это всё проблемы писателей кодогенераторов, и вполне решаемые.
Также, наверно лучше использовать для этой задачи интерфейс, а не базовый класс.
C>Какая-то очень мутная фича. Решение крайне узкой задачи, которую можно решить другими методами.
Чтобы у 1 класса был отдельный генеримый файл и отдельный рукописный (для удобства восприятия истории изменений в source control).
И без необходимости создавать лишний уровень наследования (что привело бы к удвоению кол-ва классов).
Здравствуйте, Codealot, Вы писали:
C>С чего вдруг?
Как кодогенератор от sealed класса наследника сгенерирует, чтобы в нём реализовать виртуальный метод?
C>Ты сам себе противоречишь. Или одно, или другое.
Так в одном классе нужно так, в другом иначе. Оба варианта создают сложности для кодогенераторов.
C>Ладно, пара пойнтов у тебя есть. Но это всё проблемы писателей кодогенераторов, и вполне решаемые.
Так проблемы решались и до Source Generators в том же Fody.
Но это было сложно, мало желающих было в это погружаться, а генерации людям хотелось.
Вот упростили им это, чтобы пошло в народ.
Собственно, я бы у себя в рабочем проекте несколько моментов с радостью через генераторы сделал, чтобы избавиться от копипасты, но сидим на старой версии языка и .NET Framework.
C>Также, наверно лучше использовать для этой задачи интерфейс, а не базовый класс.
Зависит от задачи. Ради генерации событий PropertyChanged во ViewModel всё писать на интерфейсах — такое себе.
O>>И без необходимости создавать лишний уровень наследования (что привело бы к удвоению кол-ва классов). C>Кхм, ты тоже экономишь классы?
Однажды я наблюдал, как молодёжь переписала "по паттернам" некое моё изделие (стоявшее на продакшене лет 10):
Бизнес-логика осталась нетронутой, но коллстек удлиннился раз в 10 или 20, и все новые шаги заключались в перекладке данных между какими-то пустыми передаточными микросервисами, каждый из которых имел свою модель сущностей предметной области, и при получении переписывал данные поле-в-поле в свои классы, а при передаче — ещё раз в чужие. На вопрос, почему не задействовать везде одну и ту же модель классов Entity Framework, ахретекторы выдавали какой-то булшыт про разделение ответственностей и принципы солид. Функционал почти не поменялся, кол-во кода и время отладки любого пустякового вопроса возросли десятикратно, но премии и повышения (и вроде даже госнаграды) пролились на эту группу как из рога изобилия. Так что возможно ты прав, экономить классы не всегда полезно.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, amironov79, Вы писали:
A>>Если тебя не удовлетворяют ответы из этой ветки, тогда лучше задать этот вопрос на гитхабе C#, там архитекторы языка обитают, они точно в курсе истинных причин
C>Там вовсе не небожители, как тебе кажется.
Но там больше шансов получить истинный ответ на волнующий тебя вопрос. На этом форуме уже человек 10 сказали, для чего они используют partial methods, что это чисто утилитарная вещь, и о фиософмких причинах их появления в языке никто не задумывался.
Здравствуйте, karbofos42, Вы писали:
K>Собственно, я бы у себя в рабочем проекте несколько моментов с радостью через генераторы сделал, чтобы избавиться от копипасты, но сидим на старой версии языка и .NET Framework.
.NET Framework не ограничивает выбор версии языка. С поднятием версии языка в проекте обычно никаких проблем не возникает.
Здравствуйте, amironov79, Вы писали:
A>.NET Framework не ограничивает выбор версии языка. С поднятием версии языка в проекте обычно никаких проблем не возникает.
Часть фич языка таки привязана к рантайму и не всё доступно на старых .NET Framework.
Ну, и у нас в проекте явно ограничение на версию языка прописано по различным причинам.
Здравствуйте, karbofos42, Вы писали:
K>Как кодогенератор от sealed класса наследника сгенерирует, чтобы в нём реализовать виртуальный метод?
Кодогенератор сам должен добавить sealed в этом случае.
K>Так в одном классе нужно так, в другом иначе. Оба варианта создают сложности для кодогенераторов.
Да, писателям кодогенераторов это действительно в некоторой степени усложнило бы жизнь.
K>Но это было сложно, мало желающих было в это погружаться, а генерации людям хотелось.
Этим и сейчас занимается крайне малое число людей.
K>Зависит от задачи. Ради генерации событий PropertyChanged во ViewModel всё писать на интерфейсах — такое себе.
А в чем собственно проблема, вынести декларации твоих событий из основного класса в интерфейс?
