Подозрительно это всё. Получается, на уровне кода не показать in-place мутабельность. А есть какие-нибудь бенчмарки сравнения с какой-нибудь Java? Обычно, в бенчмарках сплошь и рядом алгоритмы, опирающиеся на работу с массивами.
Не прыгайте с темы на тему. Мы тут секцию определений обсуждаем, и там вы дали урезанное определение ПП: "программирование используя структуры и функции"
Вот более подробное: "Procedural programming is a programming paradigm that involves implementing the behavior of a computer program as procedures (a.k.a. functions, subroutines) that call each other. Procedural programming is about dividing the program implementation into variables, data structures, and subroutines (a.k.a. functions, procedures)"
К ФП ваше определение ровным счётом никакого отношения не имеет.
Это было искреннее удивление вашему умению так быстро переобуваться. Простите, не хотел вас этим оскорбить.
Ну, а раз по существу ответить нечего, то думаю примеры полиморфизма и инкапсуляции без малейшего намёка на ООП вы без труда и сами нагуглите. Было бы желание снять давнишние шоры.
Вы бы хоть не поленились ссылку на сайт этого ЯП дать или нормально его название по-английски написать. Первый раз про такой язык слышу, как и гугл xD
И работа вся идёт без копирования.
Из приведённого примера это вовсе неочевидно. Более того, его можно 1-в-1 переписать на любом языке с иммутабельными структурами данных. Т.е. он вообще наличие мутабельности никоим образом не доказывает.
Есть много языков с элементами ФП, т.к. это действительно удобно. Но функциональных языков не так много, как минимум, они будут отличаться неизменяемостью данных и наличием оптимизации хвостовой рекурсии.
То, что вы сами не разобрались с определениями и пытаетесь свои выдумать - это просто выглядит глупо.
"программирование используя структуры и функции" - это процедурное программирование, а не функциональное.
ФП основано на лямбда-исчислении, никакого другого ФП не может существовать. Чтобы у вас было ФП, необходимо иметь first-class functions, higher order functions и иммутабельность данных. Если чего-то из этого нет, а что-то есть, то перед вами язык с элементами ФП, но не функциональный.
Хотим джава миддла с 5 годами опыта, умением писать код руками на зп в 200-250к, гибридный график (день-два офиса, остальное удаленка) в Питере. Может я слишком много прошу?
Ну, вообще да. Попробуйте 250-300k и удалёнку, сразу сильно лучше с кандидатами будет)
Так он же не писал, сколько он лет в IT. Может, до 40 лет копирайтером был, и знает такие приёмчики, как сформулировать что-то, чтобы читатель сам додумал в нужном русле)
А в чём тут хамство то? Вы попросили пример наследования без привязки к ООП. Я вам его привёл. А вы в ответ "Никакого ООП здесь нет". Ну, не сюр ли? В этом же и был тейк, что наследование бывает без ООП и вообще не является частью ООП.
Хочет клиент посмотреть историю операций - дергает 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."
Подозрительно это всё. Получается, на уровне кода не показать in-place мутабельность. А есть какие-нибудь бенчмарки сравнения с какой-нибудь Java? Обычно, в бенчмарках сплошь и рядом алгоритмы, опирающиеся на работу с массивами.
Я думал, что вы умеете гуглить по ключевым словам.
Вот вам про наследование реализации через тайп-классы, через макросы, через замыкания.
Определение ООП без наследования и полиморфизма
Вы просто взяли определение процедурного программирования xD
А функциональное обозвали математическим стилем. Это тупая подмена понятий.
Читайте внимательнее. Я утверждаю, что вы в секции определений дали определение процедурного программирования, а не функционального.
Не прыгайте с темы на тему. Мы тут секцию определений обсуждаем, и там вы дали урезанное определение ПП: "программирование используя структуры и функции"
Вот более подробное: "Procedural programming is a programming paradigm that involves implementing the behavior of a computer program as procedures (a.k.a. functions, subroutines) that call each other. Procedural programming is about dividing the program implementation into variables, data structures, and subroutines (a.k.a. functions, procedures)"
К ФП ваше определение ровным счётом никакого отношения не имеет.
Это было искреннее удивление вашему умению так быстро переобуваться. Простите, не хотел вас этим оскорбить.
Ну, а раз по существу ответить нечего, то думаю примеры полиморфизма и инкапсуляции без малейшего намёка на ООП вы без труда и сами нагуглите. Было бы желание снять давнишние шоры.
Вы лучше сами почитайте определение ФП: https://en.wikipedia.org/wiki/Functional_programming
Нет никакого отдельного "математического стиля", не выдумывайте.
Можно небольшой пример? Создаём массив со значениями от 1 до 5, меняем его первый и последний элемент местами, выводим весь массив на экран.
Вы бы хоть не поленились ссылку на сайт этого ЯП дать или нормально его название по-английски написать. Первый раз про такой язык слышу, как и гугл xD
Из приведённого примера это вовсе неочевидно. Более того, его можно 1-в-1 переписать на любом языке с иммутабельными структурами данных. Т.е. он вообще наличие мутабельности никоим образом не доказывает.
Можно что-то более наглядное? Например:
Есть много языков с элементами ФП, т.к. это действительно удобно. Но функциональных языков не так много, как минимум, они будут отличаться неизменяемостью данных и наличием оптимизации хвостовой рекурсии.
То, что вы сами не разобрались с определениями и пытаетесь свои выдумать - это просто выглядит глупо.
"программирование используя структуры и функции" - это процедурное программирование, а не функциональное.
ФП основано на лямбда-исчислении, никакого другого ФП не может существовать. Чтобы у вас было ФП, необходимо иметь first-class functions, higher order functions и иммутабельность данных. Если чего-то из этого нет, а что-то есть, то перед вами язык с элементами ФП, но не функциональный.
Ну, вообще да. Попробуйте 250-300k и удалёнку, сразу сильно лучше с кандидатами будет)
Так он же не писал, сколько он лет в IT. Может, до 40 лет копирайтером был, и знает такие приёмчики, как сформулировать что-то, чтобы читатель сам додумал в нужном русле)
Изучите для начала хоть один ФП-язык, например Elixir или Haskell, тогда поймёте, что Go вовсе не функциональный. И TS, разумеется, тоже.
А в чём тут хамство то? Вы попросили пример наследования без привязки к ООП. Я вам его привёл. А вы в ответ "Никакого ООП здесь нет". Ну, не сюр ли? В этом же и был тейк, что наследование бывает без ООП и вообще не является частью ООП.
Такой сервис-модуль 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."