Комментарии 102
Лютая каша из отдельный фраз. И очередное неправомерное приписывание изобретения современного ООП Алану Кею.
"Когда я говорил про ООП я имел ввиду совершенно не то что реализовано в С++" Алан Кей.
То что имел ввиду Алан Кей это обычные словари на сигналах, единственный фреймворк кто ее придерживается это Qt, к тому ООП что мы используем не имеет никакого отношения. То ООП которое мы знаем было реализовано в С++ Страуструпом, далее распространилась по остальным языкам: Java, C# и т.п.. Соответственно вся статья больше похоже на бредогенерацию сгенерированную ИИ на общих фразах подчерпнутых из сети.
Комментарий похож на галюцинирование нейросети) Внешне выглядит правдоподобно но недостоверно и бессмысленно.
Вот как раз его комментарий - связный и человекописный.
А я за 25 лет программирования насмотрелся бесконечного количества статей о том, что та или иная технология ну вот вот ну вот щас уже умрёт, и вот ну вот вот щас вот уже скончается.
Из них действительно скончался только шестой Internet Explorer. И тот ещё местами продолжает радовать в старых загашниках, где какой-то замурованый в стену сервер ранит всю базу данных организации.
Мне заливали, что PHP умер. Оказывается всё ещё живёт, и местами переплёвывает ноду.
Я прочитал с пол-сотни статей, о том, что NPM - это жесть полная, и она вместе с нодой умрёт, потому что появился Бан, Дено или что-то там ещё. Ну да, так и есть, а в проде я всё так же вижу.
Мне рассказывали о том, что NoSQL принесёт полную смерть и погибель SQL базам данных. Ага. Наверняка Стив Баллмер в то время, после прочтения этой статьи побежал закрывать отдел разработки MSSQL и оскользнулся, уплал и подвернул лодыжку. Только, очевидно, не добежал до закрытия.
А уж рассказов о том, как функциональные языки полностью истребят все функциональные пережитки прошлого-то.
Даже Кобол называли мёртвым языком. Только вот его хотят учить щас.
Ах, да, каждый день в интернетах выходит 2-3 статьи о новом убийце айфонов.
Поэтому, когда кто-то выходит и говорит о том, что технология, которая работает уже больше 30 лет стала бесполезной, я спокойно закрываю вкладку, и иду писать на этой технологии.
Технологии не умирают под фанфары. Никто не делает публичных похорон. Никто не устраивает "Наконец-то мы победили!" Нет. Просто в один прекрасный день кто-то встрепенётся и скажет "Блин, мне надо обслужить паровой двигатель, пойду-ка я и найду специалистов", а поктом оказывается, что специалистов нет, ты уже никому не нужен, и все об этом давным-давно забыли. В такой момент можно написать статью-ретроспективу о том, что "в 1812-м году, когда Наполеон завоёвывал Россию, в мире существовали компьютеры на тренарной логике". А эти рассуждения по поводу того, что ООП нужен или не нужен - они абсолютно бесполезны.
ООП - это инструмент. Его надо знать и знать когда применять. Если у тебя в гараже лежит шпатель и ты им не завинчиваешь шурупы, я не буду ходить и читать тебе лекции о том, что шпатель уже никому не нужен, и тебе его надо выкинуть.
Не инструмент определяет, насколько хорош программист. Только программист, который знает, как использовать инструмент, может показать, какой он хороший.
То ООП которое мы знаем
Такое ощущение, что на просторах СНГ прижилось какое-то своё C++-ориентированное ООП, и на собеседованиях здесь на вопрос про основные принципы ООП ждут ответа абстракция-инкапсуляция-наследование-полиморфизм из Шилдта или Страуструпа. Языкам Python, JavaScript, TypeScript, Go отказано в праве называться тру-ООП
В англоязычной статье на Википедии даже нет этой четверки принципов - там это всего лишь опциональные "фичи"
Я бы сказал что это основная проблема
на просторах СНГ прижилось какое-то своё
Думаю, это всё наследие borland vcl :)
Борланд тут никаким боком. Просто в реальной жизни в свое время наиболее популярные ЯП предоставляли пользователям наряду с понятием классов именно эти абстракции для реализации ООП. Многоуровневое наследование - это основа всех библиотек, использующих классы для реализации пользовательского интерфейса.
А корни проблемы скорее в том, что "Страуструп - наше все". Именно он популяризовал наследование и виртуальные функции в качестве основы ООП.
Есть, они все упоминаются в разделе 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 основных парадигм настаивает Роберт Мартин
Мартин это истина в последней инстанции?
Не совсем согласна что:
Парадигмы программирования связаны непосредственно с тем, как работают современные вычислительные системы, обрабатывающие биты. Это не концепции, это не философия.
Человек знакомый с данными "концепциями и философиями" пишет по другому на языках, не имеющих данных концепций в архитектуре (том же ассемблере).
Да, есть противоречия в рассуждениях об устаревании концепции, когда она влилась в архитектуру.
Я не читал Алана Кея и все отсылки к нему принимаю на веру. ООП для меня был и будет способом сделать программу проще. Ожидал анализа альтернатив. По факту получил натягивание мыслей Алана на микросервисную архитектуру.
Алан Кей придумал не само ООП, он ввел термин ООП для парадигмы Smalltalk (наиболее похожий представитель из сегодняшних мейнтрим языков - Python) уже после появления соответствующих концепций в других языках.
Само ООП как мы его видим в большинстве статически типизированных языков придумали в Simula, а основным популяризатором стал Страустрп, который написал свой дисер на Simula и перенес его концепции на C, создав C++.
И все как всегда.
Актуально ли ООП? Да
Умеют ли програмисты с ним работать? Зачастую нет
.
Самая большая проблема с ООП в том, что каждый пытается его понимать в меру своего разумения и получается то что вот сейчас. Терминология, прибитая к старым языкам и ожидающая что програмист владеет определенными базовыми знаниями не упрощает ситуацию.
.
Самое печальное в этом всем, что неумение в ООП не означает умение в функциональное програмирование( Сейчас большая часть продуктов адская вермишель легаси, которую спасает только тотальное покрытие тестами
Вы исходите из предпосылки, что так как почти все не умеют пользоваться ООП, то ООП хорош, просто программисты не умеют им пользоваться.
А что если ситуация другая: ООП плох для большинства задач программирования, и поэтому многие им и не пользуются в полной мере?
Ну и наконец, если есть такой инструмент для организации кода, который, по вашему мнению, недоступен для понимания большинством программистов, то он уже поэтому плох. Задача же программистов -- решить задачу заказчика, а не использовать только ООП, пока не получится, потому, что говорят, что он хорош, если по-настоящему научиться.
Задача програмистов решать задачу.
Задача хороших програмистов решать задачу так, что бы решение не порождало собой новые проблемы
А вы сейчас по классике пытаетесь оправдать говнокодинг. Не знаешь ООП - используй то что знаешь, в чем проблема то. Я нигде не говорил что ООП это золотая пуля и тд.
Каждому инструменту свое применение. Но инструментами нужно уметь пользоватся. К сожалению на сейчас очень большой процент некомпетентности, который только усугубляется тем что прохождение собеседования абсолютно никак не корелирует с реальными знаниями и навыками.
.
По последнему абзацу - все чаще встречаю ситуацию, когда уже не джуны, а "новые мидлы" не знают базовых основ по своему стеку. Про классику со структурами и тд вообще молчу. Зато как попугаи готовы повторять вызубренные термины без малейшего понимания и прямо говоря что это вообще бесполезно так как никогда им в практике не попадалось.
С таким отношением я не спорю что "большинство" совершенно не понимает базовые вещи, считая их "сложными".
Единсвенное что спасает и ужасает - chatGPT позволил таким "погромистам" еще лучше мимикрировать.
А потом охреневаешь от "решения задачи" которая выжирает в 20 раз больше оперативной памяти чем должно, потому что програмист вообще не понимает разницы между передачей среза и ссылки на срез, а тот метод что ему написал chatGPT не работает с ссылкой правильно.
Так это вам кажется, что задача решена плохо, если она выжирает в 20 раз больше оперативной памяти или там внутри "говнокодинг", который не соответствует ни ООП, ни функциональному программированию. И который, вероятно, сложно поддерживать.
А с точки зрения бизнеса ситуация может быть обратной: оперативная память стоит меньше дня работы программиста и если он запрограммировал неоптимальный алгоритм, то пофигу, зато запустились.
Говнокодинг, к примеру, тоже не страшен, потому, что проект сдохнет через 3 года сам из-за переориентации бизнеса.
На деле, предположу, что там, где оперативная память важна (программирование игр), и где важна поддержка кода (программа будет выполняться годами на МКС) с этими требованиями всё хорошо.
Поймите, отсутствие соответствия кода принципам ООП или функционального программирования = говнокодинг -- это ваше субъективное суждение.
Воистину в царстве горбатых прямая спина будет считатся уродством.
И вы опять вцепились в принципы програмирования, когда я с самого начала говорю о том что важно не средство или принцип, а умение и понимание.
Смотрите, я вот это слушаю уже много лет. Одну и туже сказку. По факту у вас ошибка выжившего. Ну, в реальности оно вон как бывает:
Бизнес, которому надо "сейчас-сейчас-сейчас" платит много денег непонятно кому, кто говнокодит.
Оно как-то выкатывается, запускается и работает.
Оно требует заваливать это ресурсами, которые ну как бы типа дешевле.
Бизнес рад, ведь запустилось.
Через 2-4 года действительно всё умирает из-за переориентации бизнеса.
Где же тут проблемы?
Проблема первая - тут как с покупкой авто. Авто это не только цена, которую заплатили продавцу, но и страховки, обслуживание и всякое такое. Т.е. считать, что автомобиль А стоит условный миллион глупо. По факту автомобиль будет стоить дороже, а при пересчёте на жизненный цикл ещё дороже.
Следовательно когда вы сравниваете память с часом работы программиста, вы делаете вид, что это равные величины, а это тёплое с мягким и при рассчёте на жизненный цикл выясняется, что заплатить разрабу за нормальную работу было выгонее .
Проблема вторая - всегда говорю, что "работает" это самая нижняя планка оценки, ниже которой с исполнителем говорить просто больше не о чем.
Хорошая оценка это "работает и соответствует вот таким критериям".
Ну, это знаете, есть копейка, а есть порш. И там и там руль, 4 колеса и они могут ездить, но есть пара нюансовю
Проблема третья - продукт умирает не естественным путём. Просто из-за проблем, допущенных на старте, развивать продукт далее становится невозможно и встаёт вопрос о том, чтобы нанаять уже нормальных людей и переделать всё с нуля. А это опять затраты. А бизнес, наверняка, планировал зарабатывать на том, что есть. А оно, внезапно, жрёт и не приносит. И бизнес просто решает забить. Ну или таки нанимает новых людей, которые начинают переделывать. Хотя по факту на ранних этапах стоимось кривого говнокода и истоимость нормальной архитектуры не особо отличалась, в том числе по времени. Просто в одном случае можно было сделать базу под продукт, спокойно его развивать, делить, масштабировать в связи с потребностями, а в другом случае просто сделали нечто, что останется в таком же виде до момента, пока реп не дропнут, чтобы не занимал места.
И нет, отсутствие ООП или функциональщины может и субъективное мнение, а отсутствие понятных подходов и стандартов это вполне себе наблюдаемая реальность на тысячах примеров. Оно примерно всегда начинается, развивается и заканчивается одинаково, но люди продолжают прыгать на граблях, ожидая иного результата. Ну конечно, я же опытный, вот в этот раз я уж точно прыгну так, что сломаю систему и грабли не ударят по лбу, а прорвут пространтвено-временной континуум и даруют мне силу джедая, молот Тора, кучу денег и пони-единорога.
По странной причине я ещё не видел богатых джедаев с молотом Тора верхом на пони-единороге, зат видел сотни заказчиков с шишаками и синяками. Даже и не знаю, к чему бы это. Может ещё разок прыгнуть, авось получится и в этот раз хреновый говнокод всё же совершит чудо?
Вопрос еще в том, а что является альтернативой?
Структурное и функциональное программирование?
Ну и наконец, если есть такой инструмент для организации кода, который,
по вашему мнению, недоступен для понимания большинством программистов,
то он уже поэтому плох.
Если развить этот силлогизм, то получится, что программирование как таковое недоступно для понимания большинством народонаселения и уже поэтому плохо вообще всё. Или вот взять скальпель - инструмент, недоступный большинству медработников, и уже поэтому плох. Да простой молоток, наверное, если щас выдать программистам, даже тем, которые по-настоящему знают ООП - многие, небось, гвозди не забьют, а вместо этого отобьют себе пальцы. Очень многое хорошо только если ему по-настоящему научиться, а до тех пор лучше не пробовать применять на практике, ибо выйдет совсем нехорошо. Ещё Ленин говорил:
Нет, конечно, вы выворачиваете наизнанку все.
если каждому хирургу рассказывают в вузе (как это происходит с ооп), что вот есть прекрасный скальпель (из вашего примера), и что это стандарт скальпелей и нужен каждому, а потом его использует на практике 1 из 100 хирургов, и никто не уволен, и люди не жалуются, то конечно плох скальпель или, как минимум, он нужен не всем.
Поэтому и не подходят примеры с программированием и всеми людьми: программирование не инструмент решения их рабочих задач. И у медиков скальпель -не инструмент решения их рабочих задач, а только у хирургов это так.
но я уверен, что вы это знаете и передергиваете специально, авось кто из аудитории не поймет разницы
Нет там никакой разницы, чтобы её понимать. ООП - вполне нормальный, рабочий и адекватный инструмент для организации кода, для использования которого не надо быть ни семи пядей во лбу, ни джедаем, ни избранным, ни магистром Хогвартца.
Так топикстартер говорит, что надо, именно поэтому, мол, он и не решает задач потому, что программисты никак не могут научиться его использовать.
вы вообще в курсе о чем я спорю?
Вы там написываете, что ООП плохо "для большинства задач программирования", то ли само по себе, то ли потому, что никто не умеет пользоваться, то ли никто не умеет пользоваться, потому что оно плохо само по себе - в любом случае плохо. Обычно про это любят писать упоротые адепты ФП, только вот их хаскели что-то никак не взлетают - лично мне, кстати, жаль, что не взлетают, потому что ФП тоже нормальный и рабочий инструмент для организации кода, не лучше ООП, просто другой, и ни то, ни другое не является "серебряной пулей". Чем я должен "подкрепить" своё мнение, я не представляю. Да и вы своё, что ООП плохо, не вижу, чтобы чем-то подкрепляли.
Ну и нет разницы — это вы просто выразили свое мнение, никак его не подкрепив. Второе предложение вообще о другом
Слышал о случаях, когда в конторе при использовании того же С++, просто на уровне стандарта разработки принималось "никакого наследования". Типа, возможность есть, но сами себе ее запретили, чтобы потом не разбираться с последствиями.
Это выглядит как "не умею ходить, поэтому отрежу себе ноги"
Так нет, потому, что наличие наследования хорошо и обязательно для поддерживаемого кода — это не факт, а мнение
А вам представляется, что это как земля крутится вокруг солнца, непреложный факт, многократно подтвержденный
Так нет, потому, что наличие наследования хорошо и обязательно для поддерживаемого кода — это не факт, а мнение
Я бы добавил, что данное мнение уже не очень популярно в современном программировании. Множественное наследование редко встретишь в современных ЯП. Наследование от интерфейса заменяется (тенденция) на типажи (traits). Всё больше классов в типичном C# проекте не имеют базового (класс object не считаем). Всё шире используются статические классы и лямбда функции.
Прямо таки просто наследования? Не "никакого множественного", не "никаких виртуальных функций", а именно "никакого наследования вообще"?
Подклассы сильно связаны с родительскими? Так, может, в этом и смысл подклассов?
Ну смысл подклассов все же быть подклассами - типом, который является полностью совместимым с родительским и подменять его, но реализует какие то собственные вариации поведения родительского.
А то, что они сильно связаны - это побочный эффект.
Если способы, как сделать классы-подтипы без сильной связи с родительскими, например при помощи композиции и интерфейсов.
Но основная проблема тут как мне кажется даже в другом.
Подклассы слишком легко ломают инкапсуляцию.
В идеале базовый класс должен быть написать так, чтобы наследник мог работать ничего не зная о нем и не заглядывая в его код
Но мы зачастую имеем противоположное.
Чтобы понять класс B во всех нюансах, нужно не только прочитать его базовый класс, но и ознакомиться со всеми прочими наследниками.
В C++ООП (которое как ООП и самого Кэя высадило в осадок) без наследования не может быть речи о полиморфизме — ты не можешь засунуть в коллекцию и однообразно взаимодействовать с разными объектами, если их типы не имеют общего предка. Вот в этом смысл.
Ну то что в C++ нет отдельного понятия "интерфейс" - это проблема C++, а не ООП.
Так и я предъявляю претензии не ООП, а именно C++. Ироническое Кэевское отношение к C++ совершенно понятно любому, кто пришёл в ООП ещё до появления C++.
В go например реализация интерфейса каким либо классом не требует никакого наследования или даже ссылки на класс. Просто свойства и функции должны биться с интерфейсом.
не может быть речи о полиморфизме
Полиморфизмы разные бывают.
ты не можешь засунуть в коллекцию и однообразно взаимодействовать с разными объектами, если их типы не имеют общего предка
Конечно же можете.
Я работаю с ООП с 10-го года. Я тупой быдлокодер, неб со звезд не хватаю и вообще тупое креведко.. не спорю ни разу, но что-то из всего что я почерпнул из опыта своего четырнадцатилетнего быдлокодинга на яве - все эти, прости, господи бестпрактикс, это попытка как-то компенсировать его минусы путем прикручивания костылей со всякими там стейтлесс классами, которые по факту превращают это няшное ООП в классическое процедурное программирование.
Витриной ООП, кмк, было старинное 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.
Но с тех пор прошло более 50 лет. И ни в каком языке программирования для вызова методов сообщения не посылаются.
Вы компетентны во всех современных языках?
Например Ruby:
https://apidock.com/ruby/Object/send
И вокруг этого имеется возможность подписываться и реагировать на кучу разных сообщений (типа method_not_found, method_added и т.д.).
Да в Ruby почти вся магия на этом построена. Ruby можно отнести к современным языкам?
проведу прагматичное исследование ООП
... странно, что не имеющее отношения к естественным наукам может подвергаться исследованию, а не анализу. Пахнет попыткой поднять ценники. Граждане, господа, леди и джентльмены - будьте разумны : применяйте употребляйте терминологию без фанатизма. Тут вроде не частная лавка, что во дворе у дома. Прошу извинить за и спрос чувства такта.
-Выходит у вас два ООП?
-Выходит - джва два!
Есть разные подходы к архитектуре. Спор на тему, какой из них является "правильным ООП", по сути является спором о терминологии, и поэтому бессмысленен.
Если взять за определение цитату Алана Кея из данной статьи, то получим, что erlang является объектно-ориентированным языком, что не мешает ему в то же время быть функциональным языком. Что касается приведённых в статье плюсов данного подхода, то того же самого можно добиться, используя другие подходы.
Если взять за определение "инкапсуляция, наследование, полиморфизм", очень популярное на рубеже веков, то этот подход в изначальном виде, практически, не используется. Разберём по пунктам.
Инкапсуляция
Кто-то понимает её как сокрытие данных, кто-то как объединение данных и методов в одном объекте. Правы и те, и другие. Её смысл в контроле состояния самим объектом - как и пункт "локальное удержание и защита, сокрытие состояния" в данной статье. То есть, у объекта нет открытых данных, а изменение данных (состояния) идёт только через методы. Но для этого недостаточно заменить "public string Name;" на "public string Name { get; set; }". "Автосвойства" нарушают этот принцип, так как контроль состояния подразумевает включения в метод name_get() валидации. Но это очевидно неудобно, а в сложных случаях и вовсе невозможно. Обычно валидацию выносят в отдельный метод (позволяет, например, собрать полный список ошибок валидации) или даже в отдельный класс (например, чтобы не дублировать код валидации по атрибутам). Инкапсуляция также подразумевает, что объект должен уметь сам себя сохранять и т.п. Это тоже неудобно, так как код сохранения обычно очень похож для разных классов объектов и больше зависит от того, куда сохраняем, чем от того, что сохраняем.
Наследование
Наследование - это ООП способ повторного использования кода. Объекты создаются по некому шаблону - описанию класса или прототипу. Наследование позволяет изменить этот шаблон и получить "такой же, но с перламутровыми пуговицами". В основе такого подхода лежит идея, что все объекты в реальном мире входят в некую иерархию, которую можно перенести в код. Но, как выяснилось, в большинстве случаев либо не входят, либо её бесполезно переносить в код. Например, в коде внешние признаки важнее генетической классификации (дельфин больше похож на рыбу, чем на котика). То есть, в реальной жизни вместо иерархии, скорее, набор меток (тэгов). В результате появляются "костыли" вроде наследования от интерфейсов, что, по сути, является ооп-способом описания абстрактных типов данных и/или классов типов.
Полиморфизм
Под полиморфизм в ООП подразумевается полиморфизм подтипов. Между тем в современных объектно-ориентированных языках широко используется обобщённый полиморфизм.
В итоге, современный подход довольно сильно отличается и от подхода Алана Кея, и от подхода "инкапсуляция, наследование, полиморфизм". И это делает упомянутый выше спор о терминологии ещё более бессмысленным.
Если взять за определение цитату Алана Кея из данной статьи, то получим, что erlang является объектно-ориентированным языком, что не мешает ему в то же время быть функциональным языком.
Всё так. Это вообще лучшее сочетание ООП и ФП:
ООП на верхнем уровне, а внутри объекта (актора) логика пишется в функциональной парадигме.
Автор сформулировал несуществующую проблему и сам путанно и подробно попытался ее распутать. С другой стороны статья полностью соответствует названию.
Из названия статьи следует, что есть критика ООП, но в статье ни ее, ни ее разбора нет, зато есть накрутка рейтинга
Стремно быть человеком, который на полном серьезе живет этими холиварными вопросами. Я предпочитаю относится к этому по-чапаевски (в пелевинском прочтении): мне вообще до звезды, актуален ли ООП. Я писал код, где джавовый ООП работал отлично. Сейчас я пишу код, где вообще никакого ООП нет. Возможно, однажды снова буду писать с ООП. Мне норм.
Актуально ли сегодня ООП?