Comments 179
Лютая каша из отдельный фраз. И очередное неправомерное приписывание изобретения современного ООП Алану Кею.
"Когда я говорил про ООП я имел ввиду совершенно не то что реализовано в С++" Алан Кей.
То что имел ввиду Алан Кей это обычные словари на сигналах, единственный фреймворк кто ее придерживается это Qt, к тому ООП что мы используем не имеет никакого отношения. То ООП которое мы знаем было реализовано в С++ Страуструпом, далее распространилась по остальным языкам: Java, C# и т.п.. Соответственно вся статья больше похоже на бредогенерацию сгенерированную ИИ на общих фразах подчерпнутых из сети.
Комментарий похож на галюцинирование нейросети) Внешне выглядит правдоподобно но недостоверно и бессмысленно.
Вот как раз его комментарий - связный и человекописный.
А я за 25 лет программирования насмотрелся бесконечного количества статей о том, что та или иная технология ну вот вот ну вот щас уже умрёт, и вот ну вот вот щас вот уже скончается.
Из них действительно скончался только шестой Internet Explorer. И тот ещё местами продолжает радовать в старых загашниках, где какой-то замурованый в стену сервер ранит всю базу данных организации.
Мне заливали, что PHP умер. Оказывается всё ещё живёт, и местами переплёвывает ноду.
Я прочитал с пол-сотни статей, о том, что NPM - это жесть полная, и она вместе с нодой умрёт, потому что появился Бан, Дено или что-то там ещё. Ну да, так и есть, а в проде я всё так же вижу.
Мне рассказывали о том, что NoSQL принесёт полную смерть и погибель SQL базам данных. Ага. Наверняка Стив Баллмер в то время, после прочтения этой статьи побежал закрывать отдел разработки MSSQL и оскользнулся, уплал и подвернул лодыжку. Только, очевидно, не добежал до закрытия.
А уж рассказов о том, как функциональные языки полностью истребят все функциональные пережитки прошлого-то.
Даже Кобол называли мёртвым языком. Только вот его хотят учить щас.
Ах, да, каждый день в интернетах выходит 2-3 статьи о новом убийце айфонов.
Поэтому, когда кто-то выходит и говорит о том, что технология, которая работает уже больше 30 лет стала бесполезной, я спокойно закрываю вкладку, и иду писать на этой технологии.
Технологии не умирают под фанфары. Никто не делает публичных похорон. Никто не устраивает "Наконец-то мы победили!" Нет. Просто в один прекрасный день кто-то встрепенётся и скажет "Блин, мне надо обслужить паровой двигатель, пойду-ка я и найду специалистов", а поктом оказывается, что специалистов нет, ты уже никому не нужен, и все об этом давным-давно забыли. В такой момент можно написать статью-ретроспективу о том, что "в 1812-м году, когда Наполеон завоёвывал Россию, в мире существовали компьютеры на тренарной логике". А эти рассуждения по поводу того, что ООП нужен или не нужен - они абсолютно бесполезны.
ООП - это инструмент. Его надо знать и знать когда применять. Если у тебя в гараже лежит шпатель и ты им не завинчиваешь шурупы, я не буду ходить и читать тебе лекции о том, что шпатель уже никому не нужен, и тебе его надо выкинуть.
Не инструмент определяет, насколько хорош программист. Только программист, который знает, как использовать инструмент, может показать, какой он хороший.
То ООП которое мы знаем
Такое ощущение, что на просторах СНГ прижилось какое-то своё C++-ориентированное ООП, и на собеседованиях здесь на вопрос про основные принципы ООП ждут ответа абстракция-инкапсуляция-наследование-полиморфизм из Шилдта или Страуструпа. Языкам Python, JavaScript, TypeScript, Go отказано в праве называться тру-ООП
В англоязычной статье на Википедии даже нет этой четверки принципов - там это всего лишь опциональные "фичи"
Я бы сказал что это основная проблема
на просторах СНГ прижилось какое-то своё
Думаю, это всё наследие borland vcl :)
Борланд тут никаким боком. Просто в реальной жизни в свое время наиболее популярные ЯП предоставляли пользователям наряду с понятием классов именно эти абстракции для реализации ООП. Многоуровневое наследование - это основа всех библиотек, использующих классы для реализации пользовательского интерфейса.
А корни проблемы скорее в том, что "Страуструп - наше все". Именно он популяризовал наследование и виртуальные функции в качестве основы ООП.
Это наследие не очень хорошего обучения программированию в постсоветских вузах где теорию ООП объясняли не дольше одной пары в терминах инкапсуляции, полиморфизма, наследования а дальше сразу переходили к C++
Есть, они все упоминаются в разделе Features на англ. Wiki: Inheritance, Data abstraction and encapsulation, Polymorphism...
ООП в JS, который официально был разработан как функциональный язык программирования? Серьезно? В языке в котором десятилетия(!) функция-конструктор была основным способом создания "обьектов"? Сейчас конечно синтаксического сахара добавили, но с точки зрения ООП - это обнять и плакать. Вот в TS Хейлсберг нормально развернулся, и функциональщина, и ооп в лучшем виде и с опытом в десятилетия.
TS изначально, а JS примерно в 2017 получил классы и наследование, как в других C-подобных языках
В $mol используется ОРП, который является частным случаем того ООП, о котором говорил Алан - объекты, динамически провязываемые каналами, по которым бегут сообщения.
Я думаю ты попадешь в историю как человек, который при любом удобном случае продвигает свой фреймворк. Веганы завидуют
Работа у меня такая, хорошие вещи продвигать:
А что вы хорошего делаете для индустрии своими едкими комментариями?
І тут у мене підгоріло!
И очередное неправомерное приписывание изобретения современного ООП Алану Кею.
Более чем правомерное. Именно Алан Кэй впервые сформулировал концепцию современного ООП и употребил это выражение.
То ООП которое мы знаем было реализовано в С++ Страуструпом, далее распространилась по остальным языкам: Java, C# и т.п..
Вот это вообще хтоническая чушь! Вы учили программирование на говнокурсах? То ООП, которое вы знаете -- это не ООП, а абстрактные типы данных. Многие их путают -- и это неправильно. ООП -- это объекты и обмен сообщениями.
Впервые же объектные принципы (объекты, классы, наследование и иные вещи) были реализованы в 1961 - 1967 в языке Simula. Это самая ранняя реализация некоторых концепций ООП.
Страуструп не изобрел ООП, он взял его из Simula. И ООП в C++ является набором костылей, прикрученных поверх C, и нужных, чтобы улучшить скорость выполнения. Нормальная реализация ООП поверх C есть в Objective-C.
Но вернёмся к истинному ООП. Гений Алан Кэй, посмотрев на Simula, понял, что можно сделать ещё лучше. И в 1967 впервые сформулировал концепцию современного ООП и, что принципиально, употребил это выражение в разговоре. Так что именно он является отцом современного ООП.
Первый язык, реализующий современное ООП вышел в 1972, и это был Smalltalk. Он вполне жив и применяется в промышленном программировании.
Холивар-то какой.
По другим источникам, изобретение Объектно-ориентированного подхода приписывается Оле-Йохану Далю и Кристену Нюгору, которые в 1966 году нашли возможность перенести кадр стека вызова функции - в динамическую память (на языке ALGOL). Что открыло возможность инкапсуляции, а затем - полиморфизма - через строгое использование указателей на функции.
Отсюда следует, что, во-первых, изобретение ООП не стоит приписывать отдельным людям. Это как радио Попова. Разные разработчики шли к этому открытию разными путями. Во-вторых, делать из ООП какую-то священную доктрину - это детский сад. У нас есть три основные парадигмы программирования: структурное, ООП, функциональное. И есть некоторое подмножество таких парадигм, как императивное, процедурное, параллельное. Часть из них можно связать с базовыми тремя. Часть больше похожи на стили, поскольку предлагают лишь философию, а не конкретику на уровне управления памятью и процессом. Часть - устарела. Поэтому, можно сказать, что кроме три базовых парадигм, других нет и не будет. По крайней мере, на современных нам вычислительных системах. Все они используются в той или иной мере каждый день. Структурное программирование предлагает нам использование циклов и условных операторов вместо прямого вызова строк кода (прямой передачи управления). Здесь можно сказать, что структурное программирование заменило императивное, доказав вред прямой передачи управления. Поэтому,то же самое процедурное программирование можно условно отнести к подмножества структурного из-за необходимости избавляться от прямых переходов. ООП определяет программные сущности, как изолированные (в том числе, физически - в памяти) объекты и определяет правила работы с ними. Функциональное программирование расширяет наш кругозор лямбда-исчислением, предлагая отказываться от изменения переменных и хранения состояния программы.
Парадигма написания программы выбирается в зависимости от задачи. Если нужно хранить состояние объекта, либо использовать полиморфизм и наследование, мы применяем ООП. Если нам нужно произвести вычисление без сохранения состояния, мы выбираем функциональный подход. Причëм, мы можем применять его даже внутри классов. А основные конструкции и блоки нам определяет структурный подход, благодаря которому мы имеем, например, циклы, итераторы, условия.
Поэтому, вся статья напоминает рассуждения в стиле "нужен ли ЦП современному компьютеру, или можно впихнуть в материнку картофелину"? Комментарии - вообще дичь. Парадигмы программирования связаны непосредственно с тем, как работают современные вычислительные системы, обрабатывающие биты. Это не концепции, это не философия. Это доказанные рабочие процессы. Поэтому, не так важно кто сформулировал те или иные принципы. Эти принципы - как законы природы. Если бы не было возможности разместить кадр стека вызова функции в динамическую память, не было бы ООП. Если бы не работала теорема Бëма-Якопини, не было бы структурного программирования. Если бы лямбда-исчисления были невозможны, не было бы и функционального подхода.
Всë обсуждение этой темы, почему-то, сводится к тому, что без Ньютона не было бы силы притяжения Земли. Так можно и до теории плоской Земли дойти, если начать спорить с концепциями Галилея и Коперника.
Декларативная и логическая парадигмы тихо плачут в сторонке из-за того, что вы их отменили.
Ну, начнëм с того, что на существовании 3 основных парадигм настаивает Роберт Мартин. А закончим тем, что HTML и SQL - не совсем языки программирования (декларативные языки не являются Тьюринг-полными), ну а логическое программироаание является вариацией программирования с использованием лямбда-исчисления, то есть, вариацией функционального программирования. О чëм, собственно, и говорит отнесение современных логических языков к функционально-логическим.
И кто такой этот ваш Роберт Мартин?
От отсутствия тьюринг-полноты язык не перестаёт быть языком программирования. К тому же есть и тюринг-полные декларативные языки.
И где вы тут нашли лямбда-исчисление? https://ru.m.wikipedia.org/wiki/Пролог_(язык_программирования)
И кто такой этот ваш Роберт Мартин?
И где вы тут нашли лямбда-исчисление? https://ru.m.wikipedia.org/wiki/Пролог_(язык_программирования)
Всё понятно. Удачи на курсах.
Спасибо. Кстати, записывайтесь, они того стоят: https://page.hyoo.ru/#!=wna7bl_3y0m1s
Рекурсивный SQL является Тьюринг-полным.
С ограничениями.
Какими ограничениями? Технические ограничения есть абсолютно в любом языке - память не бесконечна.
Вот, например, интерпретатор Brainf__k в SQL-запросе.
Ну, с определëнными допущениями, условиями и расширениями, тьюринг-машину можно собрать теоретически на чëм угодно. Это как Doom, который можно запустить хоть на хвосте собаки.
И всë-таки, я бы поставил под сомнение декларативность некоторых операций, которые делают такие языки, как SQL, тьюринг-полными. Например, операцию with. Он не описывает спецификацию ожидаемого результата, а, по сути, создаëт цикл.
Иэто уже не говоря о том, что есть время выполнения запроса и ограничения рекурсивности. С другой стороны, применимость декларативных языков к решению различных вычислительных задач - это не более чем баловство. Извините, но я не могу рассматривать декларативный подход, как парадигму программирования. Как минимум, потому, что Тьюринг-полнота декларативных языков - опциональна.
Ну, с определëнными допущениями, условиями и расширениями, тьюринг-машину можно собрать теоретически на чëм угодно.
Щито? Это математика, в ней теорема или верна, или не верна. Она не может быть верна наполовину. Язык или тьюринг-полный, или не трьюринг-полный. Если его семантика эквивалентна машине Тьюрига, он тьюринг-полный.
Ну, начнëм с того, что на существовании 3 основных парадигм настаивает Роберт Мартин
Мартин это истина в последней инстанции?
Я указываю автора технической литературы, который приводит этот тезис. Я не утверждаю, что он не может ошибаться. Но меня мало интересуют личные мнения. Если у вас есть ссылки на достаточно не противоречивые источники, где опровергается этот тезис, или приводится иной тезис, их можно рассмотреть.
Ну это же классическая отсылка к авторитету.
То есть, вы считаете, что приводить мнение технических авторов нельзя только потому, что это апелляция к авторитету?
Почему же, можно. Но насколько это будет убедительно? Мартин и откровенную ерунду писал.
Уверен, что вы - тоже.
А у Вас как раз классический аргумент к личности. Возможно у Вас есть доводы которые противоречат утверждению Мартина, помимо того что он писал ерунду?
А у Вас как раз классический аргумент к личности.
Возможно я неудачно выразился. Само по себе использование мнения Мартина как аргумент идея сомнительная.
Возможно у Вас есть доводы которые противоречат утверждению Мартина, помимо того что он писал ерунду?
Чтобы сказать точно, надо бы посмотреть где, когда и что именно писал/говорил Мартин. В изначальном сообщении никакой ссылки нет. Поэтому все зависит от контекста. Нет четкого определения, есть разные мнения какие парадигмы основные, какие побочные. Опять же в современном прикладном ПО нет четкого разделения, код часто бывает в смешанном стиле написан. Короче говоря для таких утверждений нужна развернутая аргументация. А тут вместо аргументации чисто мнение Мартина, причем без ссылки, чтобы можно было понять контекст.
Теперь по существу вопроса.
Вот, к примеру, цитата из статьи Флойда (автор самого термина) 1978 года "Парадигмы программирования"
Парадигму структурного программирования никак нельзя считать повсеместно признанной.
Наиболее ярые ее сторонники должны признать, что самой по себе ее недостаточно, чтобы превратить все сложные проблемы в простые. Сохраняют свое значение и другие более специализированные парадигмы высокого уровня, такие как метод ветвей и границ или метод "разделяй и властвуй"
Как вам парадигма "разделяй и властвуй"? Там же упоминается парадигма динамического программирования. Или "для этого я создал парадигму нахождения иерархической организации процессоров". Очевидно, что под парадигмой программирования имеется в виду более узкие вещи чем ОО или структурное программирование.
А вот статья которая так и называется "Overview of the four main programming paradigms". Тут четыре основных парадигмы - императивная, функциональная, объектно-ориентированная и логическая.
Вот статья "Programming Paradigms for Dummies: What Every Programmer Should Know", там на " Figure 2. Taxonomy of programming paradigms " вообще "There are 27 boxes, each representing a paradigm as a set of programming concepts.". 27 парадигм, да еще целая таксономия со связами и прочим.
Есть разделение на императивную и декларативную, со своими более специализированными парадигмами.
Что в итоге? Понятие не очень четко сформулированное, есть самые разные взгляды на то сколько парадигм вообще, какие основные, какие специализированные. Поэтому утверждение "есть три основные парадигмы" и аргументация - так говорил Заратустра Мартин, мне представляется крайне упрощенным и как минимум спорным.
by the way, читали ли книгу Мартина "Agile Principles, Patterns, and Practices in C#" ?
Возможно я неудачно выразился.
Возможно (скорее, точно), вы не только неудачно выразились, но и проигнорировали ту часть моих комментариев, в которых приводились доводы того, что можно выделить три основных парадигмы, а прочие являются или устаревшими, или производными от них.
Что в итоге? Понятие не очень четко сформулированное, есть самые разные взгляды на то сколько парадигм вообще, какие основные, какие специализированные.
Когда мы говорим о парадигме ООП, то мы имеем ввиду вполне конкретные вещи. А именно, возможность инкапсуляции методов и свойств в классы с применением наследования и полиморфизма. Этот подход к организации и проектированию кода стал возможным потому, что однажды удалось добиться сохранения кадра стека вызова функции в динамической памяти. То есть, появилась возможность сохранить состояние вызываемого кода на разных этапах выполнения. Использование ссылок на вложенные функции сделало возможным реализацию полиморфизма (подразумевающего наследование). То есть, этот подход к организации инструкций в коде потенциально не зависит от языка программирования (разумеется, если речь не идёт о логических или декларативных языках, но о них позже).
Структурное программирование - это имплементация теоремы Бёма-Якопини, которая ограничивает использование других способов передачи управления (например, оператора GOTO, по которому проехался в 1968 году Эдсгер Дейкстра).
Так а что же делать с императивным стилем? Я лично не считаю императивное программирование парадигмой. Это как называть Vanila JS фреймворком. Написание последовательных инструкций - это вообще не стиль. Это примитив разработки. Отсутствие структурирования. Когда мы ограничиваем методы передачи управления между отдельными строками кода ветвлениями и циклами, мы автоматически выходим на структурное программирование.
Как вам парадигма "разделяй и властвуй"?
Никак. Это логический паттерн, а не парадигма. Парадигма подразумевает набор правил написания кода, структурирования и оформления, потенциально независимо от языка программирования. То есть, мы можем применить одну из парадигм потенциально в любом языке. Хотите применить ООП в SQL? Пожалуйста! Помимо того, что существует Object-Pl/SQL, некоторые СУБД являются объектно-реляционными и позволяют, например, наследовать таблицы (https://www.cybertec-postgresql.com/en/conditional-foreign-keys-polymorphism-in-sql/). Скажу больше: оператор With в SQL наравне с применением оконных функций и Match/Case, по сути, позволяет применять структурный подход, расширяя декларативно-императивные инструкции языка циклами и ветвлениями. Кроме того, в многие СУБД позволяют писать свои функции, не сохраняющие состояние в процессе выполнения, применять цепочки вызовов функций, что делает SQL с расширениями, в том числе, функциональным языком.
Логические языки я считаю подмножеством функциональных, поскольку они основаны на том же лямбда-исчислении, просто их синтаксис более декларативный. Тот же Пролог, как сообщает беглое гугление, в современных имплементациях имеет ООП-расширения. Просто потому, что есть задачи, которые решаются именно ООП парадигмой, и это-таки настоящая парадигма.
Поэтому, я считаю, что дядюшка Мартин в своей книге "Чистая архитектура" даёт вполне верное определение как понятию Парадигма, так и трём основным существующим парадигмам. Он пишет, что Парадигма - это способ программирования, не зависящий от конкретного языка. Я бы уточнил, что это набор правил по логической организации и структуризации кода, не зависящий от конкретного языка. И это не трудно доказать: структурное программирование является имплементацией теоремы Бёма-Якопини, функциональное программирование - наиболее строгой имплементацией лямбда-исчислений, ООП - это наиболее простой и полный способ организации кода для сохранения промежуточного состояния выполнения, обеспечения наследования и полиморфизма.
Теорема Бёма-Якопини говорит о том, что любой алгоритм может быть оптимизирован до использования основных структур: последовательность, ветвление, цикл. Если некий язык не поддерживает одну из перечисленных структур, то он не полноценен, поскольку на нём не получится выполнить любую задачу.
Лямбда-исчисление тоже тесно связано с полнотой языка, поскольку предполагает наличие рекурсивности и замыканий, отсутствие которых, по сути, делает язык бесполезным. Поэтому, что-то мне подсказывает, что даже в языках, где нет анонимных функций, можно присвоить переменной ссылку на функцию, обеспечив эту самую анонимность (хотя, могу ошибаться - поправьте, если так).
ООП подразумевает, как я уже говорил, инкапсуляцию, наследование, полиморфизм (минимум - без абстракции). И существует оно для решения нескольких задач. Первая задача связана с сохранением состояния вызова функции на разных этапах её выполнения. Вторая задача - избегание повторения кода за счёт наследования или полиморфизма функций, посредством использования ссылок на них. Поэтому, в любом языке, так или иначе, или возможно это реализовать, или возможно расширить язык конструкциями, предлагающими решение этой проблемы. В любом случае, сохраняя состояние исполнения вашей программы, или определяя ссылки на вложенные функции, вы имеете дело с ООП.
Когда мы говорим о парадигме ООП, то мы имеем ввиду вполне конкретные вещи.
Именно. И эти вещи: (1) всё есть объект и (2) объекты взаимодействуют путем посылки сообщений. Вот и все принципы. Всё прочее -- это частности реализации.
А именно, возможность инкапсуляции методов и свойств в классы с применением наследования и полиморфизма.
Классы и наследование -- это частный случай реализации. Есть языки, в которых вместо них используются прототипы и композиция. Слово "полиморфизм" вообще не люблю. Что оно значит вне конкретных языков? В терминологии C++ полиморфная функция может принимать аргументы разных типов. Причём тут ООП? Это ближе к метапрограммированию. То, что разные объекты по разному отвечают на одни и те же сообщения -- является их базовым свойством.
Ещё у вас противоречащие пункты. Вот вы пишите, что:
Этот подход к организации и проектированию кода стал возможным потому, что однажды удалось добиться сохранения кадра стека вызова функции в динамической памяти. То есть, появилась возможность сохранить состояние вызываемого кода на разных этапах выполнения.
Угу, то есть частности низкоуровневой реализации сделали возможным ООП. Ну, хорошо. Но ниже, вы уже ставите телегу впереди лошади:
И существует оно для решения нескольких задач. Первая задача связана с сохранением состояния вызова функции на разных этапах её выполнения. Вторая задача - избегание повторения кода за счёт наследования или полиморфизма функций, посредством использования ссылок на них.
То есть ООП нужно, чтобы сохранить состояние вызова функции? Причём тут вообще вызовы и состояния функций? Почему вы их пихаете во все комменты?
ООП -- это концепция высокого уровня. На этом уровне нет ни функций, ни вызовов, ни указателей, -- это всё частности реализации не только языков, но и машин. На уровне ООП есть лишь объекты и сообщения.
Слово "полиморфизм" вообще не люблю. Что оно значит вне конкретных языков?
Это способность функции обрабатывать данные разных типов.
Существует три основных разновидности полиморфизма: ad-hoc, параметрический и подтипов. Например, в C# используются все 3 разновидности. ООП полиморфизм - это полиморфизм подтипов.
ООП полиморфизм — это полиморфизм подтипов.
А если нет типов?
А если нет типов?
Если Вы про языки с динамической типизацией, то там типы есть. В некоторых языках необязательно задавать интерфейсы явно. Например, в некоторых языках со статической типизацией интерфейс может быть выведен компилятором.
Что касается утиной типизации в языках с динамической типизацией, то её сложно однозначно отнести к какому-то типу полиморфизма.
Вы говорите об ООП в понимании Алана Кэя так, будто это истина в последней инстанции. Но это не так.
Кэй определяет ООП как инкапсуляцию + динамическое связывание. При этом, динамическое связывание можно назвать частным случаем реализации полиморфизма. Просто, Кэй не изучал вопрос полиморфизма. Однако, игнорировать этот вопрос только потому, что ваш любимый автор его не изучал - несколько странно.
Хочется отметить, что полиморфизм не является парадигмо-зааисимой концепцией, и может быть реализован, в том числе, в структурном подходе.
Алан Кэй ошибочно не рассматривал наследование и абстракцию, как принципы ООП, поскольку принципиально не хотел использовать его для создания абстракций и избегания повторов в коде за счëт наследования. Даже задачи, связанные с необходимостью изменения имплементации функции он решал только динамическим связыванием. Однако, уже в 1967 году Кристофер Стрэчи формулирует базовую классификацию полиморфизма. То есть, до создания языка Small talk и, соответственно, до формулирования термина "объектная ориентированность".
И вот, получается, что инкапсуляция возникла до определения Алана Кэя. Полиморфизм возник до определения Алана Кэя. Так в чëм же его заслуга, и насколько корректно ограничивать себя только ко его определением ООП?
Заслуга Алана Кэя состоит только в том, что он ввëл термин ООП впервые для системы разработки, основанной на инкапсуляции и полиморфизме (ограниченном только поздним связыванием). Поэтому, не вижу особого смысла ограничивать ООП только его определением. ООП - это комбинация инкапсуляции, полиморфизма, наследования и абстракции. Это всë не требует даже поддержки классов или обмена сообщениями. Всë является объектом в ООП? Не факт. С тем же успехом можно говорить, что в ООП всë является абстракцией, а имплементация обеспечивается поздним связыванием. Алан Кэй - не единственный автор, и термин он ввëл исключительно для описания своего Smalltalk. За пределами смолтолка, термин имеет более широкое значение.
ООП - это комбинация инкапсуляции, полиморфизма, наследования и абстракции.
Добавлю, что из всего вышеперечисленного только наследование присуще исключительно ООП. Поэтому существует мнение, что ООП - это наследование.
Разве инкапсуляция имеется в ФП?
Замыкание.
Замыкание создаётся снаружи применения функции. В классе же, поля и методы всегда будут недоступны и закрыты для доступа.
Тут скорее больше подходит механизм функций внутри функции, но не замыкания.
Замыкание - это и есть вложенная функция (функция внутри функции).
В замыкании ты получаешь функцию как результат. А захват переменных происходит тех, которые передает разработчик. Доступ в итоге получается ко всем данным на этапе разработки. В ООП в инкапсуляции ты не имеешь доступа ни к скрытым полям ни к методам.
А речь про вложенные функции шла о таком:
function GetInt: integer;
function InternalGetInt: integer;
begin
//
end;
begin
//InternalGetInt
end;Тут как раз нет доступа к внутренней функции, она скрыта от разработчика
Продемонстрируйте, пожалуйста, каррирование функции.
А захват переменных происходит тех, которые передает разработчик.
Тех, которые передаёт разработчик функции. Пользователь функции доступа к переменным не имеет.
В ООП в инкапсуляции ты не имеешь доступа ни к скрытым полям ни к методам.
Разработчик класса имеет доступ. Пользователь класса доступа к переменным (полям класса) не имеет.
void Main()
{
var a = new A(1);
var b = CreateB(11);
Console.WriteLine($"Print A: {{ X = {a.GetX()} }}");
Console.WriteLine($"Print B: {{ X = {b.GetX()} }}");
a.SetX(2);
b.SetX(22);
Console.WriteLine($"Print A: {{ X = {a.GetX()} }}");
Console.WriteLine($"Print B: {{ X = {b.GetX()} }}");
}
// Код написан разработчиком класса B
public static (Func<int> GetX, Action<int> SetX) CreateB(int x)
{
int GetX() => x;
void SetX(int y) => x = y;
return (GetX, SetX);
}
// Код написан разработчиком класса A
public class A
{
private int _X;
public int GetX() => _X;
public void SetX(int y) => _X = y;
public A(int x)
{
_X = x;
}
}Например, в JavaScript замыкания традиционно используются для создания "закрытых" полей
Разве инкапсуляция имеется в ФП?
Помимо замыканий, инкапсулировать можно на уровне модулей в Haskell/F#/Ocaml/Rust
Скорее, неизбежное следствие из инкапсуляции и полиморфизма. Если мы можем собрать функционал в одной области памяти, а в другой - переопределить часть функций, пользуясь ссылками на них, то мы получаем возможность наследования. То есть, мы можем создать копию функционала, пользуясь только ссылками на него, не создавая дубликат кода.
И это подводит нас к интересному выводу: Алан Кэй видел это неизбежное следствие, когда выводил основы ООП. Но ему не нравилась идея переиспользования кода по ссылкам на функции. Он недооценивал эту идею. Поэтому, искусственно исключил из первоначальной концепции.
> ООП - это комбинация инкапсуляции, полиморфизма, наследования и абстракции.
Добавлю, что из всего вышеперечисленного только наследование присуще исключительно ООП. Поэтому существует мнение, что ООП - это наследование.
Выше уже (очень правильно) написали, что ООП — это объекты + сообщения. Где там наследование вообще? А так же, как инкапсуляция, полиморфизм и абстракция?
Чтобы доказать, что некоторое определение (например, от Алана Кэя) чего-либо (например, ООП) — "плохое", изменим это определение, сведя его к абсолютно другим (гораздо более нетривиальным и сложным концепциям), потом будем долго рассуждать про эти самые концепции (можно ещё на практике показать, что это всё плохо работает) и в результате сделаем вывод, что это определение плохое :)
Вместо того, чтобы признать, что исходное определение и вообще идею мы не понимаем, никогда на практике её не применяли, а вместо этого занимались демагогией.
Не совсем согласна что:
Парадигмы программирования связаны непосредственно с тем, как работают современные вычислительные системы, обрабатывающие биты. Это не концепции, это не философия.
Человек знакомый с данными "концепциями и философиями" пишет по другому на языках, не имеющих данных концепций в архитектуре (том же ассемблере).
Да, есть противоречия в рассуждениях об устаревании концепции, когда она влилась в архитектуру.
С большей частью комментария согласен. Но как минимум не готов однозначно согласиться с причинно-следственной связью "не было бы возможности ..., не было бы ....". Как по мне, здесь как минимум проблема курицы и яйца. А где-то и вовсе обратная причинно-следственная связь: изначальное возникновение потребности/стремления и, как следствие, поиск какого-то из способов ее достижения.
ООП явно не тянет на отдельную парадигму, это всего лишь, скажем так, частный случай Dinamic Dispatch, причём самый простой вариант - single dispatch.
ООП появилось во времена графических интерфейсов и хорошо подходит именно как API для общения с операционной системой.
Но для других задач, например, там где часто взаимодействуют несколько равноправных объектов, ООП подходит не очень хорошо, хотя бы потому, что нельзя выделить "главный" объект. Отсюда и берут ноги "контролеры", "менеджеры" и пр. Для этих целей нужен уже multiple dispatch (но его сложнее реализовать из-за недетерминированного выбора функции).
В общем, не надо переоценивать ООП. Иногда вижу, как пытаются натянуть сову на глобус, пытаясь объяснить как надо "правильно" использовать ООП, но факт в том, что ООП действительно не очень хорошо подходит для многих задач.
А вот "pattern matching" и логическое программирование - действительно отдельные парадигмы, для них и матмодели имеются, так что утверждение, что других парадигм "нет и не будет" очевидно абсурдно
ООП явно не тянет на отдельную парадигму
ООП появилось во времена графических интерфейсов
Нет конечно. ООП родилось в эпоху тотального доминирования процедурного программирования, и я не про SmallTalk, который по практичности и распространённости уступал языку Лого. И пыталось лечить проблемы процедурщины, когда все кишки наружу (привет DTO), и добавление одного подвида чего-то-там приводило к необходимости перелопатить все switch в программе.
Я не читал Алана Кея и все отсылки к нему принимаю на веру. ООП для меня был и будет способом сделать программу проще. Ожидал анализа альтернатив. По факту получил натягивание мыслей Алана на микросервисную архитектуру.
Алан Кей придумал не само ООП, он ввел термин ООП для парадигмы Smalltalk (наиболее похожий представитель из сегодняшних мейнтрим языков - Python) уже после появления соответствующих концепций в других языках.
Само ООП как мы его видим в большинстве статически типизированных языков придумали в Simula, а основным популяризатором стал Страустрп, который написал свой дисер на Simula и перенес его концепции на C, создав C++.
Значит, то ООП, которое вы знаете — не ООП.
И все как всегда.
Актуально ли ООП? Да
Умеют ли програмисты с ним работать? Зачастую нет
.
Самая большая проблема с ООП в том, что каждый пытается его понимать в меру своего разумения и получается то что вот сейчас. Терминология, прибитая к старым языкам и ожидающая что програмист владеет определенными базовыми знаниями не упрощает ситуацию.
.
Самое печальное в этом всем, что неумение в ООП не означает умение в функциональное програмирование( Сейчас большая часть продуктов адская вермишель легаси, которую спасает только тотальное покрытие тестами
Вы исходите из предпосылки, что так как почти все не умеют пользоваться ООП, то ООП хорош, просто программисты не умеют им пользоваться.
А что если ситуация другая: ООП плох для большинства задач программирования, и поэтому многие им и не пользуются в полной мере?
Ну и наконец, если есть такой инструмент для организации кода, который, по вашему мнению, недоступен для понимания большинством программистов, то он уже поэтому плох. Задача же программистов -- решить задачу заказчика, а не использовать только ООП, пока не получится, потому, что говорят, что он хорош, если по-настоящему научиться.
Задача програмистов решать задачу.
Задача хороших програмистов решать задачу так, что бы решение не порождало собой новые проблемы
А вы сейчас по классике пытаетесь оправдать говнокодинг. Не знаешь ООП - используй то что знаешь, в чем проблема то. Я нигде не говорил что ООП это золотая пуля и тд.
Каждому инструменту свое применение. Но инструментами нужно уметь пользоватся. К сожалению на сейчас очень большой процент некомпетентности, который только усугубляется тем что прохождение собеседования абсолютно никак не корелирует с реальными знаниями и навыками.
.
По последнему абзацу - все чаще встречаю ситуацию, когда уже не джуны, а "новые мидлы" не знают базовых основ по своему стеку. Про классику со структурами и тд вообще молчу. Зато как попугаи готовы повторять вызубренные термины без малейшего понимания и прямо говоря что это вообще бесполезно так как никогда им в практике не попадалось.
С таким отношением я не спорю что "большинство" совершенно не понимает базовые вещи, считая их "сложными".
Единсвенное что спасает и ужасает - chatGPT позволил таким "погромистам" еще лучше мимикрировать.
А потом охреневаешь от "решения задачи" которая выжирает в 20 раз больше оперативной памяти чем должно, потому что програмист вообще не понимает разницы между передачей среза и ссылки на срез, а тот метод что ему написал chatGPT не работает с ссылкой правильно.
Так это вам кажется, что задача решена плохо, если она выжирает в 20 раз больше оперативной памяти или там внутри "говнокодинг", который не соответствует ни ООП, ни функциональному программированию. И который, вероятно, сложно поддерживать.
А с точки зрения бизнеса ситуация может быть обратной: оперативная память стоит меньше дня работы программиста и если он запрограммировал неоптимальный алгоритм, то пофигу, зато запустились.
Говнокодинг, к примеру, тоже не страшен, потому, что проект сдохнет через 3 года сам из-за переориентации бизнеса.
На деле, предположу, что там, где оперативная память важна (программирование игр), и где важна поддержка кода (программа будет выполняться годами на МКС) с этими требованиями всё хорошо.
Поймите, отсутствие соответствия кода принципам ООП или функционального программирования = говнокодинг -- это ваше субъективное суждение.
Воистину в царстве горбатых прямая спина будет считатся уродством.
И вы опять вцепились в принципы програмирования, когда я с самого начала говорю о том что важно не средство или принцип, а умение и понимание.
Вы с самого начала говорите, что ООП хорош, просто этого почти никто не понял. Я спорю с этим, а вы зачем-то постоянно пытаетесь сменить тему на потребление оперативной памяти, говнокодинг и спины с царствами
на самом деле это потому, что никаких доказательств того, что ООП хорош у вас и нет
Ну приведи же цитату из моих коментариев (можно даже не только из первого) где я такое говорю.
Я уже устал по кругу одно и то же писать разными формулировками. Это ты вцепился в идею что все тебе насаждают богомерзкий ООП, а говнокодинг это небходимость и доказываешь это каждому (не только мне и не только в этой ветке)
Самое страшное в том, что тебя плюсуют не боты накрутки, а реальные люди которые считают так же. Вот к этой ситуации как раз и относится моя цитата про "царства"
Смотрите, я вот это слушаю уже много лет. Одну и туже сказку. По факту у вас ошибка выжившего. Ну, в реальности оно вон как бывает:
Бизнес, которому надо "сейчас-сейчас-сейчас" платит много денег непонятно кому, кто говнокодит.
Оно как-то выкатывается, запускается и работает.
Оно требует заваливать это ресурсами, которые ну как бы типа дешевле.
Бизнес рад, ведь запустилось.
Через 2-4 года действительно всё умирает из-за переориентации бизнеса.
Где же тут проблемы?
Проблема первая - тут как с покупкой авто. Авто это не только цена, которую заплатили продавцу, но и страховки, обслуживание и всякое такое. Т.е. считать, что автомобиль А стоит условный миллион глупо. По факту автомобиль будет стоить дороже, а при пересчёте на жизненный цикл ещё дороже.
Следовательно когда вы сравниваете память с часом работы программиста, вы делаете вид, что это равные величины, а это тёплое с мягким и при рассчёте на жизненный цикл выясняется, что заплатить разрабу за нормальную работу было выгонее .
Проблема вторая - всегда говорю, что "работает" это самая нижняя планка оценки, ниже которой с исполнителем говорить просто больше не о чем.
Хорошая оценка это "работает и соответствует вот таким критериям".
Ну, это знаете, есть копейка, а есть порш. И там и там руль, 4 колеса и они могут ездить, но есть пара нюансовю
Проблема третья - продукт умирает не естественным путём. Просто из-за проблем, допущенных на старте, развивать продукт далее становится невозможно и встаёт вопрос о том, чтобы нанаять уже нормальных людей и переделать всё с нуля. А это опять затраты. А бизнес, наверняка, планировал зарабатывать на том, что есть. А оно, внезапно, жрёт и не приносит. И бизнес просто решает забить. Ну или таки нанимает новых людей, которые начинают переделывать. Хотя по факту на ранних этапах стоимось кривого говнокода и истоимость нормальной архитектуры не особо отличалась, в том числе по времени. Просто в одном случае можно было сделать базу под продукт, спокойно его развивать, делить, масштабировать в связи с потребностями, а в другом случае просто сделали нечто, что останется в таком же виде до момента, пока реп не дропнут, чтобы не занимал места.
И нет, отсутствие ООП или функциональщины может и субъективное мнение, а отсутствие понятных подходов и стандартов это вполне себе наблюдаемая реальность на тысячах примеров. Оно примерно всегда начинается, развивается и заканчивается одинаково, но люди продолжают прыгать на граблях, ожидая иного результата. Ну конечно, я же опытный, вот в этот раз я уж точно прыгну так, что сломаю систему и грабли не ударят по лбу, а прорвут пространтвено-временной континуум и даруют мне силу джедая, молот Тора, кучу денег и пони-единорога.
По странной причине я ещё не видел богатых джедаев с молотом Тора верхом на пони-единороге, зат видел сотни заказчиков с шишаками и синяками. Даже и не знаю, к чему бы это. Может ещё разок прыгнуть, авось получится и в этот раз хреновый говнокод всё же совершит чудо?
Я согласен с вами по поводу стандартов, их соблюдения, да и всего посыла, только из этого никак не следует, что ООП хорош для всех
Подождите, но этого никто и не утверждал. Конечно не для всех. Только вы в своём комментарии не говорите об этом. Фактически вы говорите "если тебе е хватает уровня и ты не освоил какую-то концепцию - игнорируй и делай как умеешь. Главное делать". Я, да и не только я, противопоставляем вам - простите, но это путь вникуда.
И никто не говорил, что функциональная разработка, допустим, это говнокод. Если вы сделали такое предположение, то вы ошиблись. Вам говорят, что именно "пишется как пишется" это плохо. И это плохо в целом как тенденция, потому с этим необходимо бороться, ведь это намеренное понижение уровня. Так мы дальше скажем что-то типа "зачем все эти алгоритмы, мапинги, коллекции, декораторы, переменные и прочие странные слова? Не надо осваивать, пиши как умеешь".
Поймите, для инженеров важна стандартизация. Они придумана не просто так, не случайно. И ООП, т.е. отношение ко всему как ко взаимодействию объектов, оно возникло не просто так. Для этого был ряд причин. И эта модель в общем случае лучшее, что есть. Она простая, понятная, гибкая, удобная. То, что она не подходит для всех случаев не делает её хуже.
Более того, фактически такой подход показал себя очень хорошо и в других сферах. Фактически мы перешли от микроуровня к макроуровню с теми же идеями. Есть микросервисы, это развитие идеи. Есть подходы в инфраструктуре, где "один контейнер - один процесс". Т.е. мы изолируем сущности - одни хранят, другие обрабатывают. И взаимодействуют они друг с другом простыми операциями, а не мы лепим комбаин, который делает всё и сразу внутри себя.
Почти во всём с вами соглашусь. Вот только далеко не всегда можно сделать монументальную архитектуру, которая переживёт годы. И не потому, что программист криворук, а потому, что требования меняются. И архитектура программы, оптимальная с точки зрения предыдущих требований, становится всё менее оптимальной по мере их изменения.
Философски, архитектура — это форма, а требования — это содержание. И по мере жизни происходит постоянный отрыв формы от содержания. Вплоть до образования превращённой формы, когда форма уничтожает своё содержание, а программа становится неподдерживаемой.
Потому вопрос не только и даже не столько в том, чтобы сразу сделать всё «правильно», поскольку правильность в плане понимания будущих требований мы далеко не всегда контролируем. Вопрос в том, чтобы регулярно рефакторить код, подправляя форму под актуальное понимание содержания.
Вопрос еще в том, а что является альтернативой?
Структурное и функциональное программирование?
Даже если бы не было никакой альтернативы, это бы не доказывало, что ООП хорошо решает поставленную перед ним задачу
Ну если нет альтернативы, то даже самый неэффективный инструмент - лучший.
Увы, но нет.
Лучший это прилагательное, которое используется при сравнении. Т.е. мы могли бы разложить "лучший на" "инструмент А более эффективный, чем инструмент Б" и подобные состовляющие. Но если есть только инструмент А, он не может быть сравнен с чем-то. Потому если нет альтернативы, то инструмент безальтернативный, а не лучший.
При этом, если он неэффективный или серьёзно проваливающийся по каким-то параметрам и это очевидно (не всегда можно в моменте узнать, что инструмент неэффективный. Например несколько сотен лет примерно никто не знал, что есть такая вещь, как электричество, а следовательно никто не знал, что свечи неэффективны, как и керосиновые лампы), стоит заняться поиском альтернативы.
Ответ на этот вопрос я ожидал прочесть в статье.
Ну и наконец, если есть такой инструмент для организации кода, который,
по вашему мнению, недоступен для понимания большинством программистов,
то он уже поэтому плох.
Если развить этот силлогизм, то получится, что программирование как таковое недоступно для понимания большинством народонаселения и уже поэтому плохо вообще всё. Или вот взять скальпель - инструмент, недоступный большинству медработников, и уже поэтому плох. Да простой молоток, наверное, если щас выдать программистам, даже тем, которые по-настоящему знают ООП - многие, небось, гвозди не забьют, а вместо этого отобьют себе пальцы. Очень многое хорошо только если ему по-настоящему научиться, а до тех пор лучше не пробовать применять на практике, ибо выйдет совсем нехорошо. Ещё Ленин говорил:
Нет, конечно, вы выворачиваете наизнанку все.
если каждому хирургу рассказывают в вузе (как это происходит с ооп), что вот есть прекрасный скальпель (из вашего примера), и что это стандарт скальпелей и нужен каждому, а потом его использует на практике 1 из 100 хирургов, и никто не уволен, и люди не жалуются, то конечно плох скальпель или, как минимум, он нужен не всем.
Поэтому и не подходят примеры с программированием и всеми людьми: программирование не инструмент решения их рабочих задач. И у медиков скальпель -не инструмент решения их рабочих задач, а только у хирургов это так.
но я уверен, что вы это знаете и передергиваете специально, авось кто из аудитории не поймет разницы
Нет там никакой разницы, чтобы её понимать. ООП - вполне нормальный, рабочий и адекватный инструмент для организации кода, для использования которого не надо быть ни семи пядей во лбу, ни джедаем, ни избранным, ни магистром Хогвартца.
Так топикстартер говорит, что надо, именно поэтому, мол, он и не решает задач потому, что программисты никак не могут научиться его использовать.
вы вообще в курсе о чем я спорю?
Вы там написываете, что ООП плохо "для большинства задач программирования", то ли само по себе, то ли потому, что никто не умеет пользоваться, то ли никто не умеет пользоваться, потому что оно плохо само по себе - в любом случае плохо. Обычно про это любят писать упоротые адепты ФП, только вот их хаскели что-то никак не взлетают - лично мне, кстати, жаль, что не взлетают, потому что ФП тоже нормальный и рабочий инструмент для организации кода, не лучше ООП, просто другой, и ни то, ни другое не является "серебряной пулей". Чем я должен "подкрепить" своё мнение, я не представляю. Да и вы своё, что ООП плохо, не вижу, чтобы чем-то подкрепляли.
Ну и нет разницы — это вы просто выразили свое мнение, никак его не подкрепив. Второе предложение вообще о другом
Слышал о случаях, когда в конторе при использовании того же С++, просто на уровне стандарта разработки принималось "никакого наследования". Типа, возможность есть, но сами себе ее запретили, чтобы потом не разбираться с последствиями.
Это выглядит как "не умею ходить, поэтому отрежу себе ноги"
Так нет, потому, что наличие наследования хорошо и обязательно для поддерживаемого кода — это не факт, а мнение
А вам представляется, что это как земля крутится вокруг солнца, непреложный факт, многократно подтвержденный
Так нет, потому, что наличие наследования хорошо и обязательно для поддерживаемого кода — это не факт, а мнение
Я бы добавил, что данное мнение уже не очень популярно в современном программировании. Множественное наследование редко встретишь в современных ЯП. Наследование от интерфейса заменяется (тенденция) на типажи (traits). Всё больше классов в типичном C# проекте не имеют базового (класс object не считаем). Всё шире используются статические классы и лямбда функции.
Тенденция в том, чтобы отвязать проблемы статической проверки корректности кода от момента компиляции, а тем более - рантайма. Ведь мы хотим, чтобы IDE посвечивала ошибки красненьким прямо в процессе ввода, а не кого-то потом. Поэтому структуры данных и типы теперь разбегаются по разным уголкам.
От интерфейса не наследуются, его реализуют.
Аналогия всего лишь аналогия.
Например, когда люди идут в пеший поход на неделю с рюкзаками, они при этом не бегут. Это не значит, что они не способны бежать. Это значит, что в данной ситуации они сочли более удобным достигать своей цели пешком, а не бегом.
Прямо таки просто наследования? Не "никакого множественного", не "никаких виртуальных функций", а именно "никакого наследования вообще"?
Мне часто говорят, что студентам не разрешается использовать некоторые части Си или Си++ (обычно это указатели), потому что они "нечитаемы". Обычно это правило навязывается руководителями, знающими ФОРТРАН, БЕЙСИК или какой-то другой язык, не поддерживающий указатели, ибо их не очень-то заставишь изучать Си. Вместо того, чтобы допустить, что их знания недостаточны, такие руководители будут лучше калечить своих программистов. Указатели отлично читаемы для программистов на Си.
Ален И. Голуб, "Веревка достаточной длины, чтобы… выстрелить себе в ногу", 1995 год.
Подклассы сильно связаны с родительскими? Так, может, в этом и смысл подклассов?
Ну смысл подклассов все же быть подклассами - типом, который является полностью совместимым с родительским и подменять его, но реализует какие то собственные вариации поведения родительского.
А то, что они сильно связаны - это побочный эффект.
Если способы, как сделать классы-подтипы без сильной связи с родительскими, например при помощи композиции и интерфейсов.
Но основная проблема тут как мне кажется даже в другом.
Подклассы слишком легко ломают инкапсуляцию.
В идеале базовый класс должен быть написать так, чтобы наследник мог работать ничего не зная о нем и не заглядывая в его код
Но мы зачастую имеем противоположное.
Чтобы понять класс B во всех нюансах, нужно не только прочитать его базовый класс, но и ознакомиться со всеми прочими наследниками.
В C++ООП (которое как ООП и самого Кэя высадило в осадок) без наследования не может быть речи о полиморфизме — ты не можешь засунуть в коллекцию и однообразно взаимодействовать с разными объектами, если их типы не имеют общего предка. Вот в этом смысл.
Ну то что в C++ нет отдельного понятия "интерфейс" - это проблема C++, а не ООП.
Так и я предъявляю претензии не ООП, а именно C++. Ироническое Кэевское отношение к C++ совершенно понятно любому, кто пришёл в ООП ещё до появления C++.
В go например реализация интерфейса каким либо классом не требует никакого наследования или даже ссылки на класс. Просто свойства и функции должны биться с интерфейсом.
Ну, польза от интерфейса в плюсах - сомнительна. По сути, породит дополнительный вид наследования вместо сегодняшней совершенно ортогональной системы наследования.
Зачем интерфейсы в PHP? Потому что нет множественного наследования.
не может быть речи о полиморфизме
Полиморфизмы разные бывают.
ты не можешь засунуть в коллекцию и однообразно взаимодействовать с разными объектами, если их типы не имеют общего предка
Конечно же можете.
Я работаю с ООП с 10-го года. Я тупой быдлокодер, неб со звезд не хватаю и вообще тупое креведко.. не спорю ни разу, но что-то из всего что я почерпнул из опыта своего четырнадцатилетнего быдлокодинга на яве - все эти, прости, господи бестпрактикс, это попытка как-то компенсировать его минусы путем прикручивания костылей со всякими там стейтлесс классами, которые по факту превращают это няшное ООП в классическое процедурное программирование.
Я вообще не программист, немного изучал Python, сейчас пробую себя в инди разработке на движке Godot, там как раз писали про схожесть с питоном и ООП направленность движка. Я сначала пробовал создавать не очень трудные классы, чтобы например инициализировать повторяющиеся вещи типо: базовый урон скила, название, тип урона, максимальный лвл и тд. А остальное дописывал в коде каждого скила, но позже начал видеть многие закономерности и уже переносил в базовый класс больше и больше, в целом это прикольно, и где то мне очень помогло выгрузить из головы лишнего, упростить создание нового и сэкономить время, была необходимость пару раз, когда базовый класс не подходил под сценарии и механики нового скила или кнопки, ну написал "в ручную". Все же считаю пользы от этого больше.
Витриной ООП, кмк, было старинное Delphi с его иерархией классов.
Не трогать Delphi, он живёт и здравствует и на нем пишут крупные проекты до сих пор. Новая версия в апреле вот выйдет
Оконный GUI, пожалуй, единственная сложная сущность которая хорошо ложиться на концепцию ООП. Не без изьяна разумеется. Первый ООП язык Smalltalk был придуман для реализации оконного интерфейса на Xerox Alto.
Старинное Delphi выпустила 12ую версию среды и компилятора в этом году
Сомнительная статья
Системы обмена сообщениями поддерживают транзакционный обмен сообщениями,
Ну вот как бы не следует что наличие сообщений обязательно приводит к поддержке транзакций
через обмен сообщениями, существенно повышается модульность, надёжность и масштабируемость.
надежность понятие по ширше чем устойчивы к сбоям
например доступность - сегодня одно rest api, а завтра другое и как бы все ломается
Почему не упомянуты прототипные языки Self и JavaScript, в которых нет классов? И вообще, классы не являются непременным атрибутом ООП.
Статья сомнительная, тут согласен - слишком похоже на ИИ стиль. Идеи хоть и здравые, но более-менее очевидные.
Для себя в целом пришел примерно к тем же принципам, исходя из опыта и прошлых ошибок:
максимально строгий и простой публичный интерфейс, скорее даже контракт, он упрощает понимание и сокращает количество ошибок, делает взаимодействие частей системы прозрачным, повышает надежность и стабильность всей системы
модульность позволяет уменьшать степень связности, скрывать реализации и все их внутренние костыли, снижает когнитивную сложность и стоимость поддержки, и, самое главное, ограничивает бесконтрольный рост сложности и размывание ответственности: границы модулей затрудняют и замедляют рост новых связей между кишками разных модулей, позволяя оставаться в рамках публичного интерфейса, не дают наращивать когнитивную сложность и уменьшают риск появления не очевидных побочных эффектов, которые возникают из-за лишних связей в обход публичного интерфейса. В идеале разграничение должно быть как можно строже, на уровне разных команд и разных приложений, так как разнесение кода по модулям в пределах одного приложения и одной команды на практике работает не очень хорошо, всегда найдется тот, кто захочет срезать углы и добавить магии и скрытых связей, чтобы сэкономить силы или время, и препятствовать такому развитию событий довольно сложно и дорого, в то время как физическое разграничение по разным командам просто не даст самой возможности выйти за пределы публичного интерфейса какому-то одному конкретному разработчику, как бы ему этого не хотелось
принцип позднего связывания, на мой взгляд, автоматически вытекает из использования публичных интерфейсов: когда все взаимодействие частей системы строго расписано, уже не особо важно как и из чего сделана каждая отдельная часть, главное чтобы они придерживались публичного интерфейса. Их можно прозрачно менять, прямо во время работы системы, комбинировать, маршрутизировать каналы сообщений, архитектура такой системы очень гибкая
Что касается всего остального - это уже в целом напоминает философию, и это уже не особо интересно, интереснее сугубо прикладная, практическая часть, то, что принесет какие-то ощутимые выгоды, такие как например снижение когнитивной нагрузки. А практика показывает, что разработчики это штука нестандартная, творческая, и сильно зависимая от опыта. У каждого свои треки развития, свой набор шишек, опыта, знаний и усвоенных концепций, набор освоенных методик и инструментов, свои лайфхаки, и своя планка сложности идей, которую способен обработать мозг. Кто-то еще просто не готов к концепциям сложнее объектов и наследования, кто-то уже нахватался философии, но пока не понимает ее, и, в желании считаться тру разработчиком, усердно везде намазывает тонны абсолютно лишних абстракций, на любые замечания гневно крича про первичность принципов, не понимая этих самых принципов, подобно религиозному фанатику, по факту только усложняя жизнь себе и коллегам, а кто-то уже набил шишки и сам пришел к тем идеям, которые ему упростили жизнь, или набрался достаточно опыта, чтобы понять и оценить практические выгоды из чужих идей, прочитанных или подсмотренных где-то, и теперь начинает это применять сам, в своей работе. И требовать тут что-то бессмысленно: если опыта недостаточно, то формально все требуемое будет соблюдено, но в таком виде, что никто этому рад не будет. Остается только направлять и подсказывать, подсвечивать тонкие моменты, и ожидать пока человек вырастет сам до достаточного уровня, чтобы применять инструменты осмысленно.
Безотносительно ООП, идея максимально гибких сочленений в программах вроде позднего связывания и очередей сообщений на уровне компонентов одного приложения скорее неудачна. В рамках одного компилируемого, или даже распространяемого приложения как раз имеет смысл вынести максимум на уровень компиляции, чтоб потом и на интеграцтонных тестах сэкономить, и по проду спецэффекты не ловить.
Вот тоже об этом подумал. Иногда это бывает нужно, а обычно нет, и вот там, где "нет", почему не проверить-то на этапе компиляции, что все "сообщения", которыми обмениваются объекты, имеют смысл для этих объектов? Раньше, помню, начинаешь работать с какой-нибудь библиотекой, функционирующей именно в парадигме обмена сообщениями именно как сообщениями, где всё "связывание" уходит в рантайм - первым делом думаешь: "о, круто!", а по-факту получаешь как бы дополнительный интерпретируемый мини-язык поверх основного компилируемого, и потом с ним горя хапнешь.
Обмен сообщениями (message passing) прекрасно реализуется без всякого ООП. Это две ортогональные друг другу концепции, они не мешают и могут взаимно дополнять друг друга.
"Обмен сообщениями" в терминологии тех годов - это то что мы сейчас называем "вызов метода".
В 1960-х никто и не слышал о микросервисах, оркестраторах, асинхронных очередях сообщений, service mesh и другой чертовщине.
Концепция "обмена сообщениями" была придумана гораздо раньше чем Вы думаете. Более того, она очень плотно используется в цифровой аппаратуре со времен мэйнфреймов. Т.е. все эти микросервисы - не что иное как давно забытое старое на новый лад. :) Просто г-н Алан Кей выкресталлизовал её в отдельную методологию программирования, вместе с рядом других идей.
PS: И если я правильно помню, то эти идеи были выражены в языке Smalltalk.
если я правильно помню, то эти идеи были выражены в языке Smalltalk
конечно, все это идет от real time и моделирования, чем именно занимался Alan Kay в молодости можно посмотреть например -
https://worrydream.com/EarlyHistoryOfSmalltalk/
хотя то что Kay делал было в общем на периферии работ того времени, с опытными людьми он общался, sage и здесь оказал большое влияние, типа сотни людей работали, полезность нечто подобного ООП для real time стала понятно быстро, другое дело что реализовать на ассемблере было трудно, но попытки были, задним числом для real time вероятно это правильный подход, особенно учитывая что все делалось на mainframes, для остального sw возможно ценность ООП не такая высокая, типа с умом надо применять, в том числе С++
Обмен сообщениями между кем и кем?
Хотя при обучении ООП часто делается упор на наследование, на самом деле это не фундаментальный атрибут ООП
да, незнание и непонимание ООП приводит еще и не к таким шедевральным "открытиям".
Ещё в статье восхищает использование доисторической терминологии "посылка сообщения" вместо современной "вызов метода". Во времена SmallTalk этот термин был вполне правомерным, так как методы в SmallTalk вызывались посылкой объектов-сообщений. Но с тех пор прошло более 50 лет. И ни в каком языке программирования для вызова методов сообщения не посылаются.
А как длинно, запутанно и с повторениями объясняются простые вещи! Да ещё зачастую неправильно. Полагаю, код, который пишет автор, столь же шедеврален.
Я их не трогал толком, но Elm (язык) и Iced (фреймворк), используемые для построения интерфейса, вроде бы посылают объекты-события. Редкость, конечно, но они существуют.
использование доисторической терминологии "посылка сообщения" вместо современной "вызов метода"
Это не просто терминология, это разные концепции - и рассуждая об изначальном ООП Кея говорить о вызове методов странно.
И ни в каком языке программирования для вызова методов сообщения не посылаются.
В Objective C используется именно Smalltalk'овский подход; в Swift'е вроде вырезали, но не уверен, что вся ObjC кодовая база в macOS умерла.
И в любом случае, на мой взгляд, независимо от используемого языка неплохо иметь хотя бы поверхностное представление о разных вариантах реализации ООП - в Smalltalk, C++, Self (хотя вместо него сгодится Javascript), Common Lisp.
Посылка сообщений также является основным механизмом в языках на базе виртуальной машины BEAM: Erlang, Elixir, Gleam.
И да, с вызовами методов тут действительно ничего общего.
Это не просто терминология, это разные концепции - и рассуждая об изначальном ООП Кея говорить о вызове методов странно.
Вызов метода можно реализовать через обиен сообщениями, а обмен сообщениями можно реализовать через вызовы методов. Но это не более чем мелкие технические детали.
Для меня ООП было есть и будет представление предметной области в виде системы взаимодействующих объектов (совсем не обязательно предметов, объектом может быть даже процесс или абстракция) с реализацией программы на основе этого представления. Остальное - не более чем инструменты для реализации данной идеи. И пофиг что там писали Кей со Страуструпом. Все-таки мелкие технические детали реализации, на которых обычно все почему-то фиксируются,, как по мне, на парадигму не тянут, а ООП всеми декларируется именно каа парадигма.
Поскольку "как на самом деле" сделать не получается, а основной посыл прикладной математики (к которой относится и само программирование) - "делать то, что нужно, так как можно", то и приходится идти на некоторое ограничение модели предметной области, чтобы иметь возможность описать ее имеющимися инструментами.
Классы, инкапсуляция, наследование, полиморфизм, сообщения - это не более чем низкоуровневые абстракции, предназначенные для упрощения воплощения предстввления предметной области в виде взаимодействующих объектов.
Что характерно, все эти инструменты (классы наследование, инкапсуляцию, полиморфизм и все остальное) можно использовать и не для ООП. И получается парадокс, когда объекты есть, а ООП нет, а вместо него обычная структурщина с функциональщиной.
Для меня ООП было есть и будет представление предметной области в виде системы взаимодействующих объектов (совсем не обязательно предметов, объектом может быть даже процесс или абстракция) с реализацией программы на основе этого представления.
Тут важно дополнить, что эти объекты должны быть независимы друг от друга. В частности, у каждого должна быть своя область памяти, а не так что запустился GC и зафризил все объекты в системе. Тогда это будет честное ООП.
"Запустился GC и зафризил все объекты в системе" и "у каждого должна быть своя область памяти" - как бы абсолютно перепендикулярны.
Фризится-то не из-за того, что структуры память разделяют, а из-за ссылок объектов друг на друга. И собственно как иначе? Объекты же должны взаимодействовать - а значит как-то друг о друге знать.
Но с тех пор прошло более 50 лет. И ни в каком языке программирования для вызова методов сообщения не посылаются.
Вы компетентны во всех современных языках?
Например Ruby:
https://apidock.com/ruby/Object/send
И вокруг этого имеется возможность подписываться и реагировать на кучу разных сообщений (типа method_not_found, method_added и т.д.).
Да в Ruby почти вся магия на этом построена. Ruby можно отнести к современным языкам?
Ещё в статье восхищает использование доисторической терминологии "посылка сообщения" вместо современной "вызов метода".
Ну что за чушь! Посылка сообщений и вызов методов – принципиально разные вещи!
Сообщение – это объект, состоящий из текстовой строки (имени сообщения) и возможного списка аргументов.
Метод – это объект, реализующий некоторую функциональность, проще говоря функция, привязанная к объекту.
Посылка сообщения – это способ коммуникации объектов. Объект, получивший сообщение, сам решает, как ему поступить с ним. Он может (1) ничего не ответить, (2) вызвать метод, соответствующий имени сообщения, (3) выбросить исключение или (4) переслать сообщение иному объекту.
Вызов метода – это вызов некоторой функции, привязанной к объекту, и передача ей возможных аргументов, вот и всё. Так что вызов метода – это лишь один из многих возможных способов реакции объекта на полученное сообщение.
Механизм сообщений является неотъемлемой частью ООП, но используется и вне его. Например, все распределённые системы параллельных вычислений (MPI) используют посылку сообщений. Поскольку сообщение – это текстовая строка и список аргументов, его можно послать по сети. Вызвать функцию или метод по сети нельзя (если вы не знали). Межпроцессные коммуникации (IPC) также используют механизм сообщений. Ибо вызвать функцию или метод из иного процесса тоже нельзя.
Так что в жизни вы постоянно используете сообщения, просто не знаете это, как и многие иные вещи.
И ни в каком языке программирования для вызова методов сообщения не посылаются.
Вы так пишите, словно Smalltalk исчез. Он живёт и используется в промышленном программировании. Не в РФ, конечно. Из более новых языков сообщения используются в Ruby.
проведу прагматичное исследование ООП
... странно, что не имеющее отношения к естественным наукам может подвергаться исследованию, а не анализу. Пахнет попыткой поднять ценники. Граждане, господа, леди и джентльмены - будьте разумны : применяйте употребляйте терминологию без фанатизма. Тут вроде не частная лавка, что во дворе у дома. Прошу извинить за и спрос чувства такта.
-Выходит у вас два ООП?
-Выходит - джва два!
Есть разные подходы к архитектуре. Спор на тему, какой из них является "правильным ООП", по сути является спором о терминологии, и поэтому бессмысленен.
Если взять за определение цитату Алана Кея из данной статьи, то получим, что erlang является объектно-ориентированным языком, что не мешает ему в то же время быть функциональным языком. Что касается приведённых в статье плюсов данного подхода, то того же самого можно добиться, используя другие подходы.
Если взять за определение "инкапсуляция, наследование, полиморфизм", очень популярное на рубеже веков, то этот подход в изначальном виде, практически, не используется. Разберём по пунктам.
Инкапсуляция
Кто-то понимает её как сокрытие данных, кто-то как объединение данных и методов в одном объекте. Правы и те, и другие. Её смысл в контроле состояния самим объектом - как и пункт "локальное удержание и защита, сокрытие состояния" в данной статье. То есть, у объекта нет открытых данных, а изменение данных (состояния) идёт только через методы. Но для этого недостаточно заменить "public string Name;" на "public string Name { get; set; }". "Автосвойства" нарушают этот принцип, так как контроль состояния подразумевает включения в метод name_get() валидации. Но это очевидно неудобно, а в сложных случаях и вовсе невозможно. Обычно валидацию выносят в отдельный метод (позволяет, например, собрать полный список ошибок валидации) или даже в отдельный класс (например, чтобы не дублировать код валидации по атрибутам). Инкапсуляция также подразумевает, что объект должен уметь сам себя сохранять и т.п. Это тоже неудобно, так как код сохранения обычно очень похож для разных классов объектов и больше зависит от того, куда сохраняем, чем от того, что сохраняем.
Наследование
Наследование - это ООП способ повторного использования кода. Объекты создаются по некому шаблону - описанию класса или прототипу. Наследование позволяет изменить этот шаблон и получить "такой же, но с перламутровыми пуговицами". В основе такого подхода лежит идея, что все объекты в реальном мире входят в некую иерархию, которую можно перенести в код. Но, как выяснилось, в большинстве случаев либо не входят, либо её бесполезно переносить в код. Например, в коде внешние признаки важнее генетической классификации (дельфин больше похож на рыбу, чем на котика). То есть, в реальной жизни вместо иерархии, скорее, набор меток (тэгов). В результате появляются "костыли" вроде наследования от интерфейсов, что, по сути, является ооп-способом описания абстрактных типов данных и/или классов типов.
Полиморфизм
Под полиморфизм в ООП подразумевается полиморфизм подтипов. Между тем в современных объектно-ориентированных языках широко используется обобщённый полиморфизм.
В итоге, современный подход довольно сильно отличается и от подхода Алана Кея, и от подхода "инкапсуляция, наследование, полиморфизм". И это делает упомянутый выше спор о терминологии ещё более бессмысленным.
Если взять за определение цитату Алана Кея из данной статьи, то получим, что erlang является объектно-ориентированным языком, что не мешает ему в то же время быть функциональным языком.
Всё так. Это вообще лучшее сочетание ООП и ФП:
ООП на верхнем уровне, а внутри объекта (актора) логика пишется в функциональной парадигме.
Если взять за определение цитату Алана Кея из данной статьи
современный подход довольно сильно отличается и от подхода Алана Кея
полезно учесть, что данная статья является переводом статьи Dick Dowdell из "Nerd For Tech", если посмотреть его остальные статьи, уровень автора станет понятным,
(imho) то что пишет Alan Kay стоит читать в оригинале, источников достаточно, про общие принципы например здесь -
https://worrydream.com/EarlyHistoryOfSmalltalk/
мне понравилось например это -
"... final comment. Hardware is really just software crystallized early. It is there to make program schemes run as efficiently as possible. But far too often the hardware has been presented as a given and it is up to software designers to make it appear reasonable. This has caused low-level techniques and excessive optimization to hold back progress in program design. As Bob Barton used to say: "Systems programmers are high priests of a low cult." One way to think about progress in software is that a lot of it has been about finding ways to late-bind, then waging campaigns to convince manufacturers to build the ideas into hardware ...
A look beyond OOP as we know it today can also be done by thinking about late-binding"
Вот это хорошая цитата! Тут такое количество комментариев, а в них все опять холиварят о всякой чушне, типа наследовать или нет. И никто не обращает внимание, на часть третью, последнюю в списке, но на мой взгляд первую по необходимости концепцию ООП/сообщений - позднее связывание! Именно эта технология нужна для коллективного создания ПО и для его модульности. (А модульность - это проверенное тысячелетиями инженерное решение сложных задач. Дробим, решаем часть, снова дробим, затем собираем во едино)
Современный ООП выглядит "выхолощеным" (Плюсы, джава и иже с ними) , т к нет в нём по факту никаких сообщений. А для позднего связывания есть только интерфейсы и полиморфизмы разных вариантов. Почему так? Да из-за эффективности на этом железе!. Классическая архитектура отделяет ОЗУ - место хранения данных и кода, от ЦПУ - места, где выполняется код. В итоге это привело к отрыву по быстродействию ЦПУ от всех остальных подсистем. А вместо решения этой проблемы бизнес приказал подставлять костыли в виде кэша, всяких предвыборок и закулисного распараллеливания не предназначенной для этого программы. Как итог, любой язык с настоящим поздним связыванием будет на порядок, а то и больше, медленнее плюсов и даже джитов, которые связывание сделают на этапе компиляции. Вот и вся история.
Теперь пару слов о "заменителях" ООП: на эту роль натягивают ФП. Но у всех чистых фп языков мало того что будут проблемы с компиляцией под такую архитектуру (здесь больше из-за попытки оперировать структурами только для чтения. Копирование памяти такая архитектура железа тоже не жалует), так ещё если язык типизированный, то там обычно нет достаточно гибких инструментов для позднего связывания. (А если не типизированный - опять же всё те же грабли с быстродействием. Лисп и Схема как пример). ООП-языки во многом научились обходить ограничения, дозируя действительно позднее связывание малыми порциями, там где оно действительно нужно ивырезав начисто сообщения, заменив их встроенными таблицами виртуальных методов. ФП-языкам это только предстоит и на этот раз нужно сделать как-то более изящно, возможно оптимизировав и железо. Интерфейсы у них есть - это алгебраические типы данных, плюс прикреплённые за счёт полиморфизма к ним функции. Остаётся добавить механизм сообщений. Возможно, как это сделано в Erlang, но не абсолютизировать, а только тогда, когда это действительно требуется.
Автор сформулировал несуществующую проблему и сам путанно и подробно попытался ее распутать. С другой стороны статья полностью соответствует названию.
Из названия статьи следует, что есть критика ООП, но в статье ни ее, ни ее разбора нет, зато есть накрутка рейтинга
Стремно быть человеком, который на полном серьезе живет этими холиварными вопросами. Я предпочитаю относится к этому по-чапаевски (в пелевинском прочтении): мне вообще до звезды, актуален ли ООП. Я писал код, где джавовый ООП работал отлично. Сейчас я пишу код, где вообще никакого ООП нет. Возможно, однажды снова буду писать с ООП. Мне норм.
Писатели этих статей, как вы уже запарили! :-)
Вы не правильно используете ООП.
ООП умер.
Что не так с ООП?
И бла-бла... Какая уже по счету статья?
Я не ищу эти статьи, они сами вылазят в рекомендациях.
Очень хочется вбросить одну тему для обсуждения и мне кажется тут самое подходящее место:
Вот смотрите, в современном "ООП на классах" наследование уже отменили, слава богам всё поняли что создание сильной связи между родителем и наследниками это источник постоянных проблем.
А давайте пойдем дальше и подумаем над инкапсуляцией. Вот смотрите, инкапсуляция в "ООП на классах" реализуется как глобальные переменные внутри класса. И в дальнейшем каждый метод класса использует эти глобальные переменные, т.е. не является чистой функцией. Тут есть явное противоречие современным методикам программирования которые утверждают что глобальные переменные это плохо и bad practice.
Как вам такое противоречие?
Разница как между частной собственностью и общественной.
Очень хочется вбросить одну тему для обсуждения и мне кажется тут самое подходящее место ....
если уж вбрасывать, лучше подумать над свежей темой - как можно использовать идеи ООП в биоинфоматике, там ситуация примерно как если бы при помощи байтового редактора мы могли менять отдельные байты в файле ОС порядка 2GB и наблюдать что получается, очень слабо представляя и формат файла и систему команд, но понятно что этот формат намного сложнее чего-нибудь типа elf или pe32, грубо говоря нужен ООП язык для описания такой структуры, естественно не только для генома человека, а вообще всего живого до бактерий,
в самом грубом приближении - основная структурная единица называется геном, сколько их точно в геноме человека неизвестно - 20-100K, такой разброс связан с тем, что далеко не все из них являются активными, типа резервные копии, + далеко не все кодируют протеины, так что есть разные определения, вообще более-менее известно назначение примерно 6К генов, про структуру отдельных генов кое-что известно - в среднем 7-8 пар последовательностей exons - intron, типа работающая часть и разделитель, далее тем кто заинтересуется надо читать статьи и пр.
зачем это надо, и что уже умеют - к примеру пару недель назад сделали первую пересадку человеку почки от специальной линии свиней с 69 отредактированными генами (для снижения риска отторжения), пока все нормально, если все будет хорошо проблем с донорами + ожидания несколько лет больше не будет, конечно это только самое начало, того что возможно уже в ближайшем будущем,
если бы был помоложе, серьезно рассмотрел бы возможность перехода в биоинфоматику, там работы хватит лет на 100, но увы 70+, из них 50 в программировании, тем кто думает о смене карьеры - вопрос к размышлению,
так что срочно требуется хороший ООП язык для описания генома, возможно что-либо уже делается, было бы интересно, если кто-нибудь может дополнить
ps
через 15 минут минус в карму, обычное дело для хабр, без разницы конечно :)
создание сильной связи между родителем и наследниками это источник постоянных проблем
Эээээ, и да и нет. Просто в привычных реализациях этого концепта решили не отделять наследуемые контракты от наследуемой реализации, то есть "я обладаю возможностями родителя = я родитель". Это, уже с точки зрения оббитых за десятилетия углов, концепция дурно пахнущая. С другой стороны, есть "внедрение вместо наследования", где все проблемы выворачиваются наизнанку. Пока что лучшая из видимых мною реализаций ненавязчивого наследования - Golang.
ООП еще как актуально, учась в магистратуре на зимней сессии сдавал экзамен по ОПП, так что актуальность данного направления программирования в стенах вузов будет еще как минимум на лет 5-10))))
Актуально ли сегодня ООП?