Хочет клиент посмотреть историю операций - дергает REST API - "дай выписку за такой-то период для такого-то клиента по такому-то счету". REST API дергает вебсервис, тот дергает наш сервис-модуль с передачей ему параметров запроса - клиент, счет, период. Сервис-модуль выполняет запрос и возвращает SQL резалтсет который уходит обратно в мобильное приложение клиента. Это синхронный механизм.
Такой сервис-модуль NRT-витрина называется в терминах data-слоя.
Но в целом, из всего того, что вы описали, выглядит так, что у вас и backend, и data-слой, и оркестратор в одну кучу свалены. Я уже даже не удивлюсь если у вас ещё и куча логики в хранимых процедурах на уровне СУБД находится. Поэтому одним словом тут не обойтись. Сейчас принято это всё на отдельных уровнях делать, и совсем разные команды каждым направлением занимаются.
Если к вам поступают данные из каких-то внешних источников, но не напрямую от пользователей (через MQ, насколько я вас понял), вы их каким-то образом обрабатываете, а потом предоставляете доступ к данным, чтобы их могли забрать другие системы, которые уже напрямую контактируют с внешним миром, то похоже, что вы делаете data-слой (ETL, OLAP, etc.)
Вот вы чем читаете? Я же пишу, что наследование, инкапсуляция и полиморфизм не имеют отношения к ООП. В этом и есть суть примера, что в нём нет ООП, а наследование реализации - есть.
defoverridable говорит о том, что можно переопределить функцию в конечном модуле
И что? Точно так же модификаторы public/protected говорят, что можно переопределить метод в какой-нибудь Java или C#
Плюс, здесь есть четкое разделение: либо старая функция, либо новая.
Наследование же предполагает, что мы берём существующий класс
Вы путаете концепцию и реализацию. Концепция наследования никаких классов не предполагает. То, что в каком-то ЯП наследование реализовано через классы - это всего лишь детали реализации в этом ЯП. И таких деталей может быть много, например, какой-то ЯП позволяет от нескольких родителей наследовать реализацию, а какой-то не позволяет.
Но ведь он не пишет, что ООП может существовать без инкапсуляции, полиморфизма, наследования...
Пишет. Вот ещё одна цитата от 2003 года (чтоб уж точно понимать, что Java и C# тоже по кривой дорожке пошли): "OOP to me means only messaging, local retention, and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."
Чуть позже он ещё признал, что языки на базе BEAM тоже реализуют концепцию ООП за счёт наличия акторной модели.
А можно, пожалуйста, примеры статей, в которых есть наследование и т.д. и без привязки к ООП?
Я ж вам пример наследования без ООП уже привёл. В разных функциональных языках это делается по разному. В Haskell через ADT, в CommonLisp через CLOS, которая все эти фишки на базе замыканий реализует. Я не вижу смысла закидывать вас десятком ссылок, поскольку это просто распылит обсуждение. А вы пока не признали, что наследование реализации возможно без ООП, хотя я вам доказательство привёл. Ведёте себя как зашоренная лошадь: "нет-нет, наследование должно быть только таким как я привык, где классы, без классов не бывает наследования", ну смешно, право слово.
Давайте тогда уж дадим определение: наследование реализации - это возможность создать один или несколько блоков кода (классов/модулей/пакетов/etc.) на базе другого (базового) без необходимости делегировать вызовы вручную (в противоположность композиции). Основная цель наследования - избежать дублирования кода реализации, т.е. функций/методов. Профит: общая точка для изменений, т.е. изменения в базовой реализации раскатываются на все дочерние. Согласны с этим?
А потом он просто подключается через use GenServer и любая функция, которая объявлена через defoverridable может быть переопределена в конечном модуле, а если не переопределишь, то будет взята реализация из базового модуля, см. пример тут: https://hexdocs.pm/elixir/GenServer.html
Что это, если не наследование реализации? Даже статьи искать не надо, из коробки уже есть.
P.S. По поводу детища Страуструпа есть прям цитата от автора ООП: "I made up the term object-oriented, and I can tell you I did not have C++ in mind."
Ну или у вас просто специфическое понимание бекенда, которое не совпадает с общепринятым мнением. Хотя само слово бекенд в целом многозначное, можно и бекенд компилятора сюда приплести. Но обычно речь идёт по умолчанию о том, что я описал.
С таким же успехом я могу сказать, что Python применяется в основном для скриптов администрирования под Linux. Он, в принципе, был создан именно для этих задач. И на момент 2005-го года буду абсолютно прав, потому что он тогда больше нигде и не применялся. То, что он сейчас ещё где-то применяется - это вообще не заслуга Python как языка. Это тупо следствие вливания в его продвижение кучи бабла.
это динамический язык с простым синтаксисом и простой семантикой
Ну, давайте сравним c Ruby и PHP. Все 3 с динамической типизацией.
У Ruby наиболее читаемый синтаксис. У PHP - C-подобный синтаксис, который многим знаком с универа. У Python - самый непривычный синтаксис, чувствительный к уровню отступов.
По семантике самый простой Ruby - есть только объекты и методы. В PHP и Python у вас есть ещё и процедуры, что повышает когнитивную нагрузку, напр. len(str), а не типичный для ООП str.length
При этом он ещё имеет огромный репозиторий готовых библиотек.
Это следствие популярности, а не причина. Вы ставите телегу впереди лошади.
Думаю, имеется в виду, что во многих ФП языках нет такого понятия как массив, есть только связный список. Да и в целом все данные неизменяемые, поэтому легко придумать синтетический тест, который будет постоянно что-то менять in-place в массивах, классическая Game of Life например, и ФП-реализация очевидно проиграет по производительности.
ФП обычно идёт неразрывно с неизменяемыми структурами данных. Это уменьшало производительность программ, актуальных в 80-90 годах. Сейчас уже разница в производительности не особо велика в подавляющем большинстве случаев, т.к. компиляторы уже научились многое оптимизировать. Зато ФП сильно повышает надёжность программ.
Ну, если вы хотите жить в мире, где подмена понятий в норме вещей, то может и не важно. Однако есть только одно официальное определение ООП - от Алана Кея. Всё остальное - это фантазии людей, которые захотели хайпануть и напридумывали извращенных трактовок.
Мне кажется, за последние 50 лет термины уже должны были устояться ;) Я бы предложил полистать книжку: Гради Буч, Объектно-ориентированный анализ и проектирование с примерами приложений.
А я вот до сих пор офигеваю от того, как легко провели тут подмену понятий, при том, что все материалы есть, с автором концепции ООП можно было свободно пообщаться и т.д.
Знаете игру "Испорченный телефон", где люди передают друг другу информацию по цепочке? Вот Гради Буч в этой игре - тот самый человек, который и сам ничего не понял, и после него вся остальная цепочка идёт по п*зде.
Уже сотни статей написаны на тему того, что наследование, инкапсуляция и полиморфизм ни малейшего отношения к ООП не имеют, и вообще абсолютно ортогональны парадигмам программирования. Но до сих пор находятся люди, которые в детстве книжку Буча почитали и с тех пор больше в этот вопрос не углублялись.
А теперь подумайте, почему сейчас Питон (как фронтенд к оптимизированному беку) - король горы во всяких научных вычислениях
Исключительно потому, что Google ему профинансировала мощную маркетинговую кампанию и поддержку в целом в конце нулевых. Тот же Ruby гораздо более ООП, чем Python. Ни одной объективной технической причины в популярности Python вы не найдёте. Одни следствия того, что кому-то в Google он субъективно понравился или как-то иначе договорились.
Вы правда собираетесь КАЖДОЙ функции передавать в качестве аргументов инстанс коннэкшна к БД?
Хоть я не автор, но отвечу. Особенность реализаций того, что сейчас принято называть ООП, в том, что по сути именно это и происходит - КАЖДОМУ методу просто в неявном виде передаётся инстанс объекта в качестве нулевого аргумента.
Такой сервис-модуль NRT-витрина называется в терминах data-слоя.
Но в целом, из всего того, что вы описали, выглядит так, что у вас и backend, и data-слой, и оркестратор в одну кучу свалены. Я уже даже не удивлюсь если у вас ещё и куча логики в хранимых процедурах на уровне СУБД находится. Поэтому одним словом тут не обойтись. Сейчас принято это всё на отдельных уровнях делать, и совсем разные команды каждым направлением занимаются.
Если к вам поступают данные из каких-то внешних источников, но не напрямую от пользователей (через MQ, насколько я вас понял), вы их каким-то образом обрабатываете, а потом предоставляете доступ к данным, чтобы их могли забрать другие системы, которые уже напрямую контактируют с внешним миром, то похоже, что вы делаете data-слой (ETL, OLAP, etc.)
С теорией то всё понятно. В теории код не надо на реальном железе выполнять.
т.е. всё-таки мы получаем ссылку на другую область памяти, а не изменяем данные in-place?
Вот вы чем читаете? Я же пишу, что наследование, инкапсуляция и полиморфизм не имеют отношения к ООП. В этом и есть суть примера, что в нём нет ООП, а наследование реализации - есть.
И что? Точно так же модификаторы public/protected говорят, что можно переопределить метод в какой-нибудь Java или C#
Не угадали. Можно из новой вызвать старую: https://onecompiler.com/elixir/43aen3cqd
Вы путаете концепцию и реализацию. Концепция наследования никаких классов не предполагает. То, что в каком-то ЯП наследование реализовано через классы - это всего лишь детали реализации в этом ЯП. И таких деталей может быть много, например, какой-то ЯП позволяет от нескольких родителей наследовать реализацию, а какой-то не позволяет.
Пишет. Вот ещё одна цитата от 2003 года (чтоб уж точно понимать, что Java и C# тоже по кривой дорожке пошли): "OOP to me means only messaging, local retention, and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."
Чуть позже он ещё признал, что языки на базе BEAM тоже реализуют концепцию ООП за счёт наличия акторной модели.
Я ж вам пример наследования без ООП уже привёл. В разных функциональных языках это делается по разному. В Haskell через ADT, в CommonLisp через CLOS, которая все эти фишки на базе замыканий реализует. Я не вижу смысла закидывать вас десятком ссылок, поскольку это просто распылит обсуждение. А вы пока не признали, что наследование реализации возможно без ООП, хотя я вам доказательство привёл. Ведёте себя как зашоренная лошадь: "нет-нет, наследование должно быть только таким как я привык, где классы, без классов не бывает наследования", ну смешно, право слово.
Давайте тогда уж дадим определение: наследование реализации - это возможность создать один или несколько блоков кода (классов/модулей/пакетов/etc.) на базе другого (базового) без необходимости делегировать вызовы вручную (в противоположность композиции). Основная цель наследования - избежать дублирования кода реализации, т.е. функций/методов. Профит: общая точка для изменений, т.е. изменения в базовой реализации раскатываются на все дочерние. Согласны с этим?
Ну, вот смотрите, возьмём чисто функциональный Elixir и посмотрим, как там ключевой компонент стандартной библиотеки (GenServer) реализован:
Вот код базового модуля: https://github.com/elixir-lang/elixir/blob/v1.18.2/lib/elixir/lib/gen_server.ex#L844
А потом он просто подключается через
use GenServerи любая функция, которая объявлена черезdefoverridableможет быть переопределена в конечном модуле, а если не переопределишь, то будет взята реализация из базового модуля, см. пример тут: https://hexdocs.pm/elixir/GenServer.htmlЧто это, если не наследование реализации? Даже статьи искать не надо, из коробки уже есть.
P.S. По поводу детища Страуструпа есть прям цитата от автора ООП: "I made up the term object-oriented, and I can tell you I did not have C++ in mind."
Ну или у вас просто специфическое понимание бекенда, которое не совпадает с общепринятым мнением. Хотя само слово бекенд в целом многозначное, можно и бекенд компилятора сюда приплести. Но обычно речь идёт по умолчанию о том, что я описал.
Вы опять телегу с лошадью местами путаете.
С таким же успехом я могу сказать, что Python применяется в основном для скриптов администрирования под Linux. Он, в принципе, был создан именно для этих задач. И на момент 2005-го года буду абсолютно прав, потому что он тогда больше нигде и не применялся. То, что он сейчас ещё где-то применяется - это вообще не заслуга Python как языка. Это тупо следствие вливания в его продвижение кучи бабла.
Эта дискуссия нас никуда не приведёт. Загуглите какие-нибудь туториалы по Ruby для начинающих, и сами поймёте, что Python тут ничем не проще.
Вы бы хоть уточняли, куда завезли и как там у них с мутабельностью?
Не сходится, Ruby долгое время был популярнее Python. А PHP так был популярнее их обоих.
Ну, давайте сравним c Ruby и PHP. Все 3 с динамической типизацией.
У Ruby наиболее читаемый синтаксис. У PHP - C-подобный синтаксис, который многим знаком с универа. У Python - самый непривычный синтаксис, чувствительный к уровню отступов.
По семантике самый простой Ruby - есть только объекты и методы. В PHP и Python у вас есть ещё и процедуры, что повышает когнитивную нагрузку, напр.
len(str), а не типичный для ООПstr.lengthЭто следствие популярности, а не причина. Вы ставите телегу впереди лошади.
Не судите только про ФП по данной статье. Я даже не знаю, чем надо было думать, чтобы взять TypeScript и Go в качестве примеров функциональных языков.
Думаю, имеется в виду, что во многих ФП языках нет такого понятия как массив, есть только связный список. Да и в целом все данные неизменяемые, поэтому легко придумать синтетический тест, который будет постоянно что-то менять in-place в массивах, классическая Game of Life например, и ФП-реализация очевидно проиграет по производительности.
ФП обычно идёт неразрывно с неизменяемыми структурами данных. Это уменьшало производительность программ, актуальных в 80-90 годах. Сейчас уже разница в производительности не особо велика в подавляющем большинстве случаев, т.к. компиляторы уже научились многое оптимизировать. Зато ФП сильно повышает надёжность программ.
Ну, если вы хотите жить в мире, где подмена понятий в норме вещей, то может и не важно. Однако есть только одно официальное определение ООП - от Алана Кея.
Всё остальное - это фантазии людей, которые захотели хайпануть и напридумывали извращенных трактовок.
А я вот до сих пор офигеваю от того, как легко провели тут подмену понятий, при том, что все материалы есть, с автором концепции ООП можно было свободно пообщаться и т.д.
Знаете игру "Испорченный телефон", где люди передают друг другу информацию по цепочке? Вот Гради Буч в этой игре - тот самый человек, который и сам ничего не понял, и после него вся остальная цепочка идёт по п*зде.
Уже сотни статей написаны на тему того, что наследование, инкапсуляция и полиморфизм ни малейшего отношения к ООП не имеют, и вообще абсолютно ортогональны парадигмам программирования. Но до сих пор находятся люди, которые в детстве книжку Буча почитали и с тех пор больше в этот вопрос не углублялись.
Вы тут сами запутались. Для ФП принципиально важно, чтобы были first-class functions и HOF, без этого действительно получится ПП
Исключительно потому, что Google ему профинансировала мощную маркетинговую кампанию и поддержку в целом в конце нулевых. Тот же Ruby гораздо более ООП, чем Python. Ни одной объективной технической причины в популярности Python вы не найдёте. Одни следствия того, что кому-то в Google он субъективно понравился или как-то иначе договорились.
Хоть я не автор, но отвечу. Особенность реализаций того, что сейчас принято называть ООП, в том, что по сути именно это и происходит - КАЖДОМУ методу просто в неявном виде передаётся инстанс объекта в качестве нулевого аргумента.
Модель акторов гораздо лучше для проектирования систем подходит. И придумали лет 40 назад уж. Хотя в те времена - это и называлось ООП)