Comments 12
Типы и объекты в вашем коде, при отправке вовне, будут упрощены до структур данных. Необходимо учитывать упрощение моделей в программе, что аналогично учёту потерь в реляционных моделях. И заботиться о том, что на другой стороне API, модели будут адекватно восстановлены и использованы вами или другими разработчиками без искажений. Это дополнительная нагрузка и увеличение ответственности программиста. Вне кода, вне помощи трансляторов/компиляторов и других автоматических инструментов при создании программ, необходимо вновь и вновь заботиться о корректной передаче моделей.
Если посмотреть на вопрос с другой стороны, то пока не видно на горизонте технологий и инструментов легко передающих типы/объекты из программы на одном языке в программу на другом.
Как вы себе представляете передачу объекта из программы работающей в одном задании в программу, работающую в другом? Я уж не говорю о том, что эти программы могут работать вообще на разных машинах…
Дело не в технологиях или разных языках. Дело в том, что объект существует в памяти конкретного задания. И передать его (кстати, что вы понимаете под «передать объект» вообще?) в другое задание можно только в виде набора данных, нужных для инициализации копии этого объекта.
Если говорить применительно к IRIS и ObjectScript, то соответствующие механизмы встроены в среду исполнения IRIS. Тут даже придумывать ничего не требуется — достаточно наследоваться от класса %Persistent.
За всеми этими красивыми словами все равно кроется передача данных на основе которых создается копия объекта. Иначе никак, увы. Если принимающая и передающая стороны работают хотя бы в разных заданиях (не говоря уже о разных машинах), память их друг другу недоступна и все что они могут, это обмениваться данными (причем, по значению, не по ссылке). Но не объектами.
Так что в любом случае
Типы и объекты в вашем коде, при отправке вовне, будут упрощены до структур данных.
А что уж там поверх этого наворочено второй вопрос. И насколько эффективно оно наворочено.
Во-первых, делать «второй экземпляр» объекта на той стороне или после передачи копии «уничтожить оригинал», решать вам. Как минимум два экземпляра, скорее всего, меняться будут несинхронно и перестанут быть копиями со всеми вытекающими по слиянию, хранению, первенству…
Во-вторых, память может быть совместно доступна. Зависит от архитектуры железа (UMA), операционной системы и вашей системы. Именно так сейчас работает macOS на M1. Вполне реальная ситуация.
В-третьих, про «только данные» или DTO — это в рантайме часто, но не всегда. Есть IRIS — платформа, где можно динамически подгружать новые реализации методов и классов. А уж в дизайнтайме у вас всегда всё в руках в любых языках и налюбых платформах — и методы, и структуры данных.
Небольшое в-червёртых, есть подозрение, что Хуавей готовит новый язык и платформу с динамическим изменением рантайма. Будет собственный язык или кросс-языковая поддержка — подождём посмотрим.
Как вы себе представляете передачу объекта из программы работающей в одном задании в программу, работающую в другом? Я уж не говорю о том, что эти программы могут работать вообще на разных машинах…
Хм, Вы не нюхали CORBA? И таки да, объект передаётся, передаётся между программами, между языками программирования, между разными машинами. И методы срабатывают через RPC.
Она, правда, как бы умерла, но труп — вот он, валяется.
А умерла она, как мне кажется, захлебнувшись собственной чёрной магией. И для приложений, не обременённых избыточным пафосом, она была бы явным оверинжинирингом. REST проще и, главное, прозрачнее. С него тупо легче стрясти банан имея лишь палку, а кушать хочется и программистам и менеджёрам.
Но если заглянуть чуть глубже, то увидите, что где-то там внизу (совсем внизу) все равно идет передача данных и создание на их основе копии объекта (термин «объект по значению»). Или «линка» на удаленный объект («ссылка на объект»).
Ну не бывает чудес. Не сможете вы напрямую обратится к объекту, который расположен в адресном пространстве другого задания. Можно организовать удаленные вызовы для получения свойств (данных) этого объекта или удаленный вызов его метода с передачей параметров и возвратом результата, но и там и там вам придется передавать и получать данные. А вот получить ссылку на этот объект и по ней вызвать метода или обратиться к данным вы не сможете. Ибо ссылка — это фактически адрес. В памяти другого задания, куда вам доступ закрыт.
Кажется, у нас с Вами терминология не сходится. Вы говорите об "объекте" исключительно как о конкретной реализации концепции ООП в рамках адресного пространства процессора, а не как об абстракции. А передачу объекта ограничиваете передачей ссылки. Но если копать ещё глубже, даже в этом случае Вы тоже не можете "напрямую обратится к объекту". Вы можете лишь накидать в стек параметры и адрес возврата и передать управление на новый адрес. На этом уровне объектов не существует даже и в Вашем представлении, а память так вообще плоская, как блин. Есть только пара сотен команд и их аргументы. Всё.
А если объект — это всё-таки абстракция, обладающая определёнными признаками (свойства и методы), и предназначенная для решения конкретной прикладной задачи, то в определённых условиях не так уж важно, что там внизу — передача данных или передача ссылки. Что-то вроде такого: "Вы же не сможете передать объект по ссылке!" — "Ну да, маршалинг под капотом. И чо?"
Впрочем, на практике сейчас принято разделение: DTO отдельно, методы отдельно. И получилось почему-то просто и удобно, в отличие от.
объект — это всё-таки абстракция, обладающая определёнными признаками (свойства и методы), и предназначенная для решения конкретной прикладной задачи
Именно так я его и рассматриваю. Вне зависимости от его реализации.
Вы же сами говорите, что:
Типы и объекты в вашем коде, при отправке вовне, будут упрощены до структур данных. Необходимо учитывать упрощение моделей в программе, что аналогично учёту потерь в реляционных моделях. И заботиться о том, что на другой стороне API, модели будут адекватно восстановлены и использованы вами или другими разработчиками без искажений.
И тут я согласен — именно так это и происходит. На нижнем уровне. Дальше на все это уже навернуто фреймворков, которые все это скрывают и для неодумляющегося разработчика делают вид, что он передает куда-то «объект». Хотя фактически идет только передача данных и ничего более.
Впрочем, на практике сейчас принято разделение: DTO отдельно, методы отдельно. И получилось почему-то просто и удобно, в отличие от.
Ничто не ново под луной… Эти подходы я использовал еще в начале 90-х годов. Причем данные могли придти как из из соседней задачи на том же компе, так и от удаленного промконтроллера по каналу RS-485.
Меж тем, SQL воспринимать как DTO сложнее. Модель предметной области вполне может хорошо ложиться на реляционное представление. Тогда запросы SQL оказываются настоящими «методами».
Четыре API для базы данных