Сообщение Re[2]: Шаблонный код в Java/Kotlin - возможно ли? от 16.10.2023 20:39
Изменено 16.10.2023 20:40 rus blood
Re[2]: Шаблонный код в Java/Kotlin - возможно ли?
Здравствуйте, r0nd, Вы писали:
R>С точки зрения вашей генерилки на основе XSD-схемы они все-таки разные.
Верно.
Логически это классы разных документов.
Но у них у всех есть одинаковый набор атрибутов.
Причем, в xsd есть общий базовый тип для них, и часть атрибутов объявлено в базовом типе.
А честь — нет, и хз почему...
R>Чем обусловлено ваше стремление "подружить" разные классы?
Весь этот зоопарк нужно сконвертировать в один класс dto.
Соответственно, с каждым классом чтение одних и тех же полей, одинаковым образом.
При этом, есть еще фишка.
Каждый квартал гос.учреждение выпускает обновление этих xsd.
Фактически, это новая версия и новый набор классов, каждые 3 месяца.
И как минимум одну предыдущую версию нужно поддерживать.
R>Предположу что находятся generated-sources?
Ээээ, наврено.
RB>>Классы авто-генерируются по xsd во время сборки.
RB>>Файлы xsd берутся с сайта гос-учреждения, корректировать невозможно.
R>Их можно локально добавить в resources. Чтобы обеспечить офлайн сборку без прямого соединения (из CI/CD например).
Ну, файлы xsd и выложены в resources.
CI/CD с сайта их не берет.
R>В Kotlin вы можете использовать интерфейсы и обобщенные функции, чтобы достичь подобного поведения, как в вашем примере на C++ с шаблонными функциями. Вам не нужно выносить общие поля в общий класс, и вы можете работать с классами, имеющими общие поля, используя интерфейсы и обобщенные функции.
Звучит, как то, что нужно.
Можете показать пример?
R>Следует помнить, что вы будете работать со своими объектами DTO (а не с экземплярами XSD-модели). Таким образом вы сможете дополнительно контролировать, если вдруг XSD-модель внезапмно изменится. В этом случае сборка просто не соберется (потому что мэппинг XSD-in-DTO не найдется) — и это будет сигнал об ошибке.
Ну, суть функционала в том и состоит, чтобы сконвертировать входное xml-сообщение во внутреннее представление (dto), и не зависеть от формата входных данных.
R>С точки зрения вашей генерилки на основе XSD-схемы они все-таки разные.
Верно.
Логически это классы разных документов.
Но у них у всех есть одинаковый набор атрибутов.
Причем, в xsd есть общий базовый тип для них, и часть атрибутов объявлено в базовом типе.
А честь — нет, и хз почему...
R>Чем обусловлено ваше стремление "подружить" разные классы?
Весь этот зоопарк нужно сконвертировать в один класс dto.
Соответственно, с каждым классом чтение одних и тех же полей, одинаковым образом.
При этом, есть еще фишка.
Каждый квартал гос.учреждение выпускает обновление этих xsd.
Фактически, это новая версия и новый набор классов, каждые 3 месяца.
И как минимум одну предыдущую версию нужно поддерживать.
R>Предположу что находятся generated-sources?
Ээээ, наврено.
RB>>Классы авто-генерируются по xsd во время сборки.
RB>>Файлы xsd берутся с сайта гос-учреждения, корректировать невозможно.
R>Их можно локально добавить в resources. Чтобы обеспечить офлайн сборку без прямого соединения (из CI/CD например).
Ну, файлы xsd и выложены в resources.
CI/CD с сайта их не берет.
R>В Kotlin вы можете использовать интерфейсы и обобщенные функции, чтобы достичь подобного поведения, как в вашем примере на C++ с шаблонными функциями. Вам не нужно выносить общие поля в общий класс, и вы можете работать с классами, имеющими общие поля, используя интерфейсы и обобщенные функции.
Звучит, как то, что нужно.
Можете показать пример?
R>Следует помнить, что вы будете работать со своими объектами DTO (а не с экземплярами XSD-модели). Таким образом вы сможете дополнительно контролировать, если вдруг XSD-модель внезапмно изменится. В этом случае сборка просто не соберется (потому что мэппинг XSD-in-DTO не найдется) — и это будет сигнал об ошибке.
Ну, суть функционала в том и состоит, чтобы сконвертировать входное xml-сообщение во внутреннее представление (dto), и не зависеть от формата входных данных.
Re[2]: Шаблонный код в Java/Kotlin - возможно ли?
Здравствуйте, r0nd, Вы писали:
R>С точки зрения вашей генерилки на основе XSD-схемы они все-таки разные.
Верно.
Логически это классы разных документов.
Но у них у всех есть одинаковый набор атрибутов.
Причем, в xsd есть общий базовый тип для них, и часть атрибутов объявлено в базовом типе.
А честь — нет, и хз почему...
R>Чем обусловлено ваше стремление "подружить" разные классы?
Весь этот зоопарк нужно сконвертировать в один класс dto.
Соответственно, с каждым классом чтение одних и тех же полей, одинаковым образом.
При этом, есть еще фишка.
Каждый квартал гос.учреждение выпускает обновление этих xsd.
Фактически, это новая версия и новый набор классов, каждые 3 месяца.
И как минимум одну предыдущую версию нужно поддерживать.
R>Предположу что находятся generated-sources?
Ээээ, наверно.
RB>>Классы авто-генерируются по xsd во время сборки.
RB>>Файлы xsd берутся с сайта гос-учреждения, корректировать невозможно.
R>Их можно локально добавить в resources. Чтобы обеспечить офлайн сборку без прямого соединения (из CI/CD например).
Ну, файлы xsd и выложены в resources.
CI/CD с сайта их не берет.
R>В Kotlin вы можете использовать интерфейсы и обобщенные функции, чтобы достичь подобного поведения, как в вашем примере на C++ с шаблонными функциями. Вам не нужно выносить общие поля в общий класс, и вы можете работать с классами, имеющими общие поля, используя интерфейсы и обобщенные функции.
Звучит, как то, что нужно.
Можете показать пример?
R>Следует помнить, что вы будете работать со своими объектами DTO (а не с экземплярами XSD-модели). Таким образом вы сможете дополнительно контролировать, если вдруг XSD-модель внезапмно изменится. В этом случае сборка просто не соберется (потому что мэппинг XSD-in-DTO не найдется) — и это будет сигнал об ошибке.
Ну, суть функционала в том и состоит, чтобы сконвертировать входное xml-сообщение во внутреннее представление (dto), и не зависеть от формата входных данных.
R>С точки зрения вашей генерилки на основе XSD-схемы они все-таки разные.
Верно.
Логически это классы разных документов.
Но у них у всех есть одинаковый набор атрибутов.
Причем, в xsd есть общий базовый тип для них, и часть атрибутов объявлено в базовом типе.
А честь — нет, и хз почему...
R>Чем обусловлено ваше стремление "подружить" разные классы?
Весь этот зоопарк нужно сконвертировать в один класс dto.
Соответственно, с каждым классом чтение одних и тех же полей, одинаковым образом.
При этом, есть еще фишка.
Каждый квартал гос.учреждение выпускает обновление этих xsd.
Фактически, это новая версия и новый набор классов, каждые 3 месяца.
И как минимум одну предыдущую версию нужно поддерживать.
R>Предположу что находятся generated-sources?
Ээээ, наверно.
RB>>Классы авто-генерируются по xsd во время сборки.
RB>>Файлы xsd берутся с сайта гос-учреждения, корректировать невозможно.
R>Их можно локально добавить в resources. Чтобы обеспечить офлайн сборку без прямого соединения (из CI/CD например).
Ну, файлы xsd и выложены в resources.
CI/CD с сайта их не берет.
R>В Kotlin вы можете использовать интерфейсы и обобщенные функции, чтобы достичь подобного поведения, как в вашем примере на C++ с шаблонными функциями. Вам не нужно выносить общие поля в общий класс, и вы можете работать с классами, имеющими общие поля, используя интерфейсы и обобщенные функции.
Звучит, как то, что нужно.
Можете показать пример?
R>Следует помнить, что вы будете работать со своими объектами DTO (а не с экземплярами XSD-модели). Таким образом вы сможете дополнительно контролировать, если вдруг XSD-модель внезапмно изменится. В этом случае сборка просто не соберется (потому что мэппинг XSD-in-DTO не найдется) — и это будет сигнал об ошибке.
Ну, суть функционала в том и состоит, чтобы сконвертировать входное xml-сообщение во внутреннее представление (dto), и не зависеть от формата входных данных.