Основная цель любой статьи — пиар. Ты пишешь на хабр, что бы люди про тебя узнали. про тебя, или про то что ты делаешь. Ну и в целом, сообщество решает, какие статьи ему нужны, а какие нет.
Он не верит во всякие переходы на .Net Core, разбиение монолита, микросервисный подход и высокие нагрузки.
Всегда в таких случаях вспоминаю свою работу, на которой использовался C# 2.0
Видимо у них тоже нашёлся 10-летний синьор, который не верит, не знаю. Но суть в том, что кодовая база от этого точно не выиграла. То, что даже в C# 4 автоматизируется одной строкой, там приходилось решать сотнями строк.
Можно сделать похожее. К сожалению, придётся за это платить тайпчеком на стадии компиляции, но вообще, мне это нравится больше, чем сотни DTO. А тут ещё и присваивание можно автоматизировать
что все эти правила преобразования из А в Б могут быть действительно где угодно, размазанные по кодовой базе
Так же, как и ваши DTO которые вы можете складировать куда угодно, называть как угодно, и использовать как угодно. Половину из них вам может быть лень выделять в отдельные DTO, и вы обмажете их атрибутами мапинга — которые все кейсы покрыть не смогут. Это ещё усугубляется моментом, что класс в Java — это не данные, это данные+поведение, в кейсе с DTO мы используем его как дынные, что гарантируется только конвенциями, а не ЯПом.
Тут ещё момент с инстанцированием, код в стиле
var userDto = new UserDto(
user.getId(),
user.getName(),
user.getSome(),
....
);
которого в кодовой базе серьёзного проекта просто море — это кошмар.
В тайпскрипте это легко автоматизировать (очень легко).
Это ещё хорошо, если разработчик использует конструкторы для DTO, я встречал подходы в C#, когда все свойства делают с сеттерами, что бы костылить присваивание через рефлексию.
Помимо этого, есть претензии к Optional типу.
В Java нет юнионов, но при разработке они нужны — встроенный тип Optional тому подтверждение — это закостыленный с помощью контрактов юнион, который по сути ничего не гарантирует (да, он даёт варнинг, которых в большом проект могут быть тысячи). И даже если бы он работал как надо — реализация через контракты, это костыль.
Свой аналог типа-объединения без контрактов тоже не получиться сделать — например пытаться эмулировать его наследованием можно, но если он будет содержать дженерики (а кому нужны юнионы без дженериков?) — то он будет страшно неудобен в использовании.
Нет адекватной интерполяции строк.
Вести разработку в чём-то кроме идеи — невозможно, потому что половина проекта работает на кодогенерации
Отсутствие дженериков в рантайме в языке со статической, строгой номинативной типизацией — вызывает кучу вопросов. и добавляет кучу неудобств.
Подход в JPARepository, когда наследуешь интерфейс, пишешь в нём методы, а реализацию за тебя дописывают (я, если честно, не знаю. кто или что это делает) исходя из букв в названии метода — явно не от большого богатства системы типов сделан.
В целом, общая претензия такая — у ЯПа нищая, просто обездоленная система типов, которая не позволяет детально выразить даже самый простой домен.
Я могу их иметь где угодно, в той же папке UserDto например. Логика в том, что эти «заклинания» короче классов, и тут нет перечисления одного и того же. Я не хочу дублировать код, вот где логика
При таком ландшафте я бы предпочёл не иметь в кодовой базе 50 DTOшек, которые во многом друг друга повторяют, и все являются отображением одного конкретного класса.
И тут вся проблема — кто то любит плодить одинаковый, зато явный код, кто-то выбирает автоматизацию, в обмен на снижение эксплиситности. Но в Java у тебя нет выбора.
Контексты задач разные, домены разные, в программировании очень редко можно сказать — всегда делай так, а не иначе. Поэтому я считаю инструменты, которые дают меньше пространства и выбора — отсталыми и неудобными.
Это не масштабируется. Грубо говоря, есть у меня структура данных User.
И ещё 50 производных от неё струткур, которые требуются клиенту.
Типа там, здесь мне нужен юзер со списком его покупок, тут юзер с метаинформацией о посещениях, тут нужен он же со списком своих друзей и т.д.
На стороне сервера у меня есть сущность User, которая всё это опосредованно содержит.
Фигачить от неё 50 dto, каждая из которых наследует базовую дто с общими полями (хотя я сомневаюсь, что такие вообще будут) — это совсем не похоже на автоматизацию.
Кроме того, наследование подразумевает расширение, в то время как мне при создании DTO часто нужно сужение.
Короче, подход с наследование избавит меня от бойлерплейта в одном с половиной случае, так я ещё и заплачу за это лишним классом UserDtoBase.
А ломбок хорошо только тем, что лечит болезни джавы (через костыль с кодогенерацией и плагин к IDE), его трудно понимать как аргумент против ЯПов, у которых нет таких болезней
Использование термина «строгая типизация» — опрометчивая идея.
Вы явно под этим понимаете «номинативная типизация», это разные вещи.
Если грубо, номинативная — это когда имя типа является его частью, а строгая, это когда компилятор не занимается автоматическими имплиситными кастами.
Теперь по вопросу.
я хочу примерно так:
// псевдокод
class A {
id: int
name: string
}
let dtoA = A.withMapping(id, (id) -> id.toString);
// и тут мне нужно, что бы типа dtoA
// выводился на стадии компиляции, как
class DtoA {
id: string
name: string
}
То-есть, я хочу и тайпчекинг(и в компайл тайме, и в рантайме), и модификацию типов данных «на лету», и без бойлерплейта с перечислением всех филдов.
В Java так не получится. А в typescript можно провернуть и не такое.
В целом, со всем моим уважением к возможностям Java и её инфраструктуры (многие из которых уникальные), мне очень не нравится по 100 раз перечислять одни и те же поля — ну это же явно автоматизируется теоретически.
Насколько я понимаю, когда начали делать реакт, тайпскрипт не был стандартом индустрии. И Фейсбук ставил на свой FlowTypes. Сейчас довольно странно начинать проект на чистом js
Я понял, что что-то не так, когда на vanilla js на одном собеседовании за час сделал прототип приложения, на которое на React у меня ушло бы добрых два. Нет, ну не может так быть
Ещё как может. Компонентный подход же, который на ваниле придётся руками делать. И он начинает давать преимущества не на стадии «прототип за час»
Вы же, «король разработки», нашли в реакте подход «компонент отображает входные данные на пользовательский интерфейс» или «абстрагирует меня от работы с DOM», хотя это никакого отношения не имеет к React и общее почти для всех frontend-фреймворков
Эти штуки есть в реакте, и в остальных фреймворках тоже есть. Я сказал, что мне от ui фреймворка нужно только это (компонентынй подход — как раз таки реализация абстрагирования от DOM).
Во вторых аргумент к социальному доказательству хорошо работает в маркетинге
Ну, какое утверждение (теория заговора про пиар реакта ради того, что бы никто не сделал сайт лучше фейсбука), такой и аргумент в ответ
Всегда в таких случаях вспоминаю свою работу, на которой использовался C# 2.0
Видимо у них тоже нашёлся 10-летний синьор, который не верит, не знаю. Но суть в том, что кодовая база от этого точно не выиграла. То, что даже в C# 4 автоматизируется одной строкой, там приходилось решать сотнями строк.
Так же, как и ваши DTO которые вы можете складировать куда угодно, называть как угодно, и использовать как угодно. Половину из них вам может быть лень выделять в отдельные DTO, и вы обмажете их атрибутами мапинга — которые все кейсы покрыть не смогут. Это ещё усугубляется моментом, что класс в Java — это не данные, это данные+поведение, в кейсе с DTO мы используем его как дынные, что гарантируется только конвенциями, а не ЯПом.
Тут ещё момент с инстанцированием, код в стиле
которого в кодовой базе серьёзного проекта просто море — это кошмар.
В тайпскрипте это легко автоматизировать (очень легко).
Это ещё хорошо, если разработчик использует конструкторы для DTO, я встречал подходы в C#, когда все свойства делают с сеттерами, что бы костылить присваивание через рефлексию.
Помимо этого, есть претензии к Optional типу.
В Java нет юнионов, но при разработке они нужны — встроенный тип Optional тому подтверждение — это закостыленный с помощью контрактов юнион, который по сути ничего не гарантирует (да, он даёт варнинг, которых в большом проект могут быть тысячи). И даже если бы он работал как надо — реализация через контракты, это костыль.
Свой аналог типа-объединения без контрактов тоже не получиться сделать — например пытаться эмулировать его наследованием можно, но если он будет содержать дженерики (а кому нужны юнионы без дженериков?) — то он будет страшно неудобен в использовании.
Нет адекватной интерполяции строк.
Вести разработку в чём-то кроме идеи — невозможно, потому что половина проекта работает на кодогенерации
Отсутствие дженериков в рантайме в языке со статической, строгой номинативной типизацией — вызывает кучу вопросов. и добавляет кучу неудобств.
Подход в JPARepository, когда наследуешь интерфейс, пишешь в нём методы, а реализацию за тебя дописывают (я, если честно, не знаю. кто или что это делает) исходя из букв в названии метода — явно не от большого богатства системы типов сделан.
В целом, общая претензия такая — у ЯПа нищая, просто обездоленная система типов, которая не позволяет детально выразить даже самый простой домен.
И тут вся проблема — кто то любит плодить одинаковый, зато явный код, кто-то выбирает автоматизацию, в обмен на снижение эксплиситности. Но в Java у тебя нет выбора.
Контексты задач разные, домены разные, в программировании очень редко можно сказать — всегда делай так, а не иначе. Поэтому я считаю инструменты, которые дают меньше пространства и выбора — отсталыми и неудобными.
И ещё 50 производных от неё струткур, которые требуются клиенту.
Типа там, здесь мне нужен юзер со списком его покупок, тут юзер с метаинформацией о посещениях, тут нужен он же со списком своих друзей и т.д.
На стороне сервера у меня есть сущность User, которая всё это опосредованно содержит.
Фигачить от неё 50 dto, каждая из которых наследует базовую дто с общими полями (хотя я сомневаюсь, что такие вообще будут) — это совсем не похоже на автоматизацию.
Кроме того, наследование подразумевает расширение, в то время как мне при создании DTO часто нужно сужение.
Короче, подход с наследование избавит меня от бойлерплейта в одном с половиной случае, так я ещё и заплачу за это лишним классом UserDtoBase.
А ломбок хорошо только тем, что лечит болезни джавы (через костыль с кодогенерацией и плагин к IDE), его трудно понимать как аргумент против ЯПов, у которых нет таких болезней
В целом, да
Использование термина «строгая типизация» — опрометчивая идея.
Вы явно под этим понимаете «номинативная типизация», это разные вещи.
Если грубо, номинативная — это когда имя типа является его частью, а строгая, это когда компилятор не занимается автоматическими имплиситными кастами.
Теперь по вопросу.
я хочу примерно так:
// псевдокод
class A {
id: int
name: string
}
let dtoA = A.withMapping(id, (id) -> id.toString);
// и тут мне нужно, что бы типа dtoA
// выводился на стадии компиляции, как
class DtoA {
id: string
name: string
}
То-есть, я хочу и тайпчекинг(и в компайл тайме, и в рантайме), и модификацию типов данных «на лету», и без бойлерплейта с перечислением всех филдов.
В Java так не получится. А в typescript можно провернуть и не такое.
В целом, со всем моим уважением к возможностям Java и её инфраструктуры (многие из которых уникальные), мне очень не нравится по 100 раз перечислять одни и те же поля — ну это же явно автоматизируется теоретически.
А писать новую DTO, которая перечисляет все поля существующей, не хочу. Как автоматизировать?
Ещё как может. Компонентный подход же, который на ваниле придётся руками делать. И он начинает давать преимущества не на стадии «прототип за час»
Эти штуки есть в реакте, и в остальных фреймворках тоже есть. Я сказал, что мне от ui фреймворка нужно только это (компонентынй подход — как раз таки реализация абстрагирования от DOM).
Ну, какое утверждение (теория заговора про пиар реакта ради того, что бы никто не сделал сайт лучше фейсбука), такой и аргумент в ответ