А, ну да! Конечно! Теоретические принципы не нужны — вам. Уметь думать не нужно — тоже вам. Ничто, кроме инкапсуляции, не интересует — вас. Почему. А не понимаю — я!
И да, я не понимаю. Например, не понимаю, что вы делаете тут в комментариях по не интересным вам теоретическим вопросам, когда вокруг столько практики для вас.
Почему объяснять ООП через инкапсуляцию — это плохая идея, я, судя по отсутствию рациональных контр-аргументов, показал.
Тратить время на очередной цикл развенчания безосновательных утверждений — как старых, так и постоянно накидываемых новых (включая, к примеру очень показательный пример с предположением — сформулированном как утверждение, и именно в этом-то и проблема; в рассуждениях об ООП она проявляется точно так же — о том, что я не застал Ada) я смысла не вижу.
P.S.: А готовить хотелось бы людей, которые умеют думать, учиться и понимать, что и почему они делают. Тех, кто просто вызубрил "умные" латинские слова, чтобы на бессмысленных интервью ими пробивать себе путь на галеры, а потом жаловаться на то, что их говнокод "ООП" не работает, и поэтому надо срочно искать другую "парадигму" (чтобы и её так же исковеркать, и, исходя из "практических соображений", деградировать до уровня условной "инкапсуляции" или аналогичног абсурда), и так хватает. Только вот всё идёт к тому, что даже при желании "схоластов" очень скоро готовить будет некому и негде — университеты усиленно сводят к уровню ПТУ. И свою лепту в этот процесс вы тоже вносите ;)
P.P.S.: Ещё одно возможное название для данной статьи "Идеи, до смысла которых мы не доросли".
Был когда-то такой язык — Pascal. У него было множество реализаций. Очень плотно им занималась компания Borland. В какой-то момент — было это в районе 89-го года в Turbo Pascal версии 5.5 — эта компания (на сколько я помню, криво-косо, но таки) начала добавлять в этот язык объектно-ориентированные "фичи".
А до этого, в районе 86-го года в версии 3.0 появились так называемые "модули" (units). Правда в мануале к "тройке" я их описания не нашёл, но в документации к версии 4.0 описано, вроде бы, неплохо.
К чему я это… Модули в Pascal в полной мере реализовывали понятие "инкапсуляция" (в обеих её ипостасях):
это объединение части данных, представляющих состояние программы и кода, который с этими данными работает, причем с этими данными работать может только этот код
Но никакого отношения к ООП ни модули, ни сам язык (на тот момент) не имели. Инкапсуляция есть, а ООП нет.
Пока не решен вопрос с состоянием объекта (…)
В ООП состояние объекта — деталь реализации. Его можно решать по-разному, но вот сама концепция от этого не изменится. Суть ООП заключается именно в том, что все вычисления есть результат обмена сообщениями между объектами. Есть состояние у конкретного объекта или нет его — просто-напросто не важно!
Но дело даже не в этом.
Если вводить понятие "инкапсуляция", неизбежно придётся объяснять, что это такое. Для этого придётся вводить другие понятия — как минимум, "данные", "методы"… К тому же, придётся объяснять, что инкапсуляция — это двойственное понятие… И т.д. и т.п. В итоге, понятие "инкапсуляция" будет сложнее, чем понятие "ООП". Но что самое обидное, инкапсуляция сама по себе всё равно не даст понятия об ООП. ООП из инкапсуляции просто-напросто не выводится.
А вот из определения Кэя выводятся и делаются понятными (в контексте ООП) и "инкапсуляция", и "полиморфизм", и "наследование". То есть, если рассказывать, например, студентам, что такое ООП, то сначала лучше рассказать про объекты и сообщения, а потом уже пояснить, что имеют ввиду, когда говорят про трёх-четырёх "китов" ООП. Пояснить и предложить забыть, чтобы не забивать голову ерундой.
Как опытный лектор, могу с уверенностью сказать. что читать лекции сейчас — практически бессмысленное занятие :D
Полностью согласен, что обсуждение любого предмета надо с рассмотрения вопросов "почему?" и "зачем?". Но это же не значит, что можно начинать с чего угодно…
Акторная модель, действительно, имеет — вполне можно сказать — прямое отношение к ООП. Но тогда уж надо рассказывать историю целиком:
как Хьюитт придумал Planner с идеей "бросания" в базу знаний паттерна (вместо прямого вызова процедуры), в ответ на что система сама решала, какие теоремы задействовать;
как Кэй "украл" и положил эту идею в основу Smalltalk-72 (видимо, до него его ещё и в -71, но про него я знаю ещё меньше), что и стало воплощением придуманного им термина "объектно-ориентированного программирования" (sic! — та самая двоица объекты-сообщения);
как потом Хьютт посетил лекцию Кэя и пере-украл идею "вычисления как обмен сообщениями между объектами", но решил, что синхронная обработка сообщений ему не подходит, и запихнул в акторы почтовые ящики для сообщений (кажется, существенно всё усложнив, но тут я не берусь ничего утверждать наверняка).
Если бы модель акторов получила большую известность, чем ООП, смысл начинать с неё, и раскручивать историю в обратную сторону, возможно и был бы. Но про акторы, в отличие от ООП сегодня слышали "не только лишь все, мало кто о ней слышал". Так что, подозреваю, студентов такая логика изложения от очень сложной темы распределённых вычислений и малоизвестной и сложной модели акторов к ООП может только запутать. Но в любом случае это лучше, чем ссылаться "на три кита" ООП.
А вот что действительно могло бы заинтересовать и объяснить, почему и зачем родилось это самое ООП — это рассказ про то, как Кэй в 1968 году придумал "iPad"… Хотя нет, он придумал гораздо более крутую штуку, чем iPad. iPad изначально создавался для потребления. А Dynabook придумывался для созидания. И именно поэтому понадобилась операционная система, которая не просто бы делала для пользователя то, что в неё заложили создатели, а позволяла бы пользователю создавать новую функциональность. А пользователями должны были стать… дети(!) И именно поэтому понадобился (принципиально) новый язык программирования: одновременно максимально простой (что-то типа упрощённого английского) и при этом максимально мощный (способствующий воплощению идей пользователей этого языка). Вот здесь и родилось то самое ООП, которые мы потеряли…
провоцирует нас делать строгое разделение: вот тут у нас наши исходники, где мы стараемся писать чисто, красиво и аккуратно, а вот тут тесты, к которым стандартные приемы не применимы.
Что или кто здесь ограничивает применимость "стандартных приёмов"?
Например, кто мешает вместо копипаста портянки под // Arrange вынести этот код в отдельный объект и начать формировать удобную в использовании и недублируемую тестовую инфраструктуру для вашей системы?
Кто мешает разбить этот тест с пятью условиями (из-за которых вы, по всей видимости, тут же ниже жалуетесь на проверку конфигурации) на 5 разных тестов? Которые, кстати, должны были быть написаны в другом месте, в другое время — потому что к тестируемой функциональности не имеют отношения.
Наконец, кто мешает хотя бы проверку цены после применения скидки записать без дублирования magic numbers?
Тут мы легко занимаемся копипастом, потому что "ну не переписывать же эту портянку из when...thenReturn", тут мы легко делаем бешенную связанность и завязываем наш код на внутреннее состояние, ведь по другому они не конфигруируются и т.д.
То есть, переписывать портянку не хотят разработчики?
Этот отказ от стандартных практик
Отказываются, как следует из контекста, тоже разработчики.
и провоцирует нас еще больше захламлять наши тесты и делать их все меньше пригодными для нас самих.
А "провоцируют" и виноваты в конечном итоге моки?
Получается так, что статью следовал бы назвать "О современной разработке. Часть 1: Плохому танцору и моки — это технический долг".
Никак не могу оставить в прошлом, одну историю, произошедшую со мной больше 7 лет назад.
На тот момент я, еще студент последнего курса учаги, только получил свою первую шабашку... Осмотревшись по сторонам, понимаю, что кругом меня не то что других молодых нет, но даже разнорабочих. Сплошные дядьки-петровичи с опытом до колена и красными с похмелья лицами... Ну ничего, сейчас я им покажу, что такое «молодая гвардия» 😂.
Получаю спецовку, стакан и струмент. Мне подробнее рассказывают куда что приколачивать. … И на третьем гвозде головка отлетает и отбивает мне большой палец на левой ноге. Я насаживаю головку обратно, и через три гвоздя она опять отлетает и снова отбивает мне большой палец на левой ноге. Больше того, смущает ситуация, что ни у бригадира, ни у кого из мужиков такого не происходит. Молоток стабилен, да и в нем не меняли ничего уже довольно давно. Вывод: проблема на моей стороне и разбираться мне с ней самому.
…
Пытаюсь откопать, от куда этот молоток мог вообще попасть, и сталкиваюсь с суровой реальностью: количество молотков на складе измеряется штуками и все точно такие же — грязные, с перемотанной синей изолентой, растрескавшейся рукояткой, и без клиньев.
…
Молотки, по своей сути, должны быть простым инструментом для забивания гвоздей. Но вместо этого, он становится источником повышенной опасности. Это не нормально, что вместо того, чтоб забивать гвозди, мы чаще смотрим на код, чтоб понять, как работает тест. Сложность насаживания головки и перематывания рукоятки изолентой на столько большая, что мужики стараются забить болт на забивания гвоздей, заколачивая только «там, где нах надо».
Но ведь мы — работяги: мы рождены, чтобы забивать гвозди без боли в большом пальце левой ноги. Почему мы не можем справиться с какими-то гвоздями? Я утверждаю, что проблема в молотках. То как мы вынуждены их заматывать синим скотчем, и следить за полётом головки провоцирует нас делать строгое разделение: вот тут у нас кувалды, где мы стараемся закрепить головку с помощью клина как следует, а вот тут молотки, к которым стандартные приемы не применимы. Тут мы легко сматываем километры синей изоленты, потому что "ну не покупать же новый молоток, он на две бутылки водки потянет, а то и три".
Вы хотите обсуждать здесь личные мнения? Я уже сказал, что не разделяю оптимизма по поводу рациональности этого.
Тем более, что в обсуждаемой статье уже есть ответ на поставленный вопрос:
Давайте называть тех, кто может получать и отправлять письма "объектами", а сами письма будем называть "сообщениями".
И, хотя изложенная в статье "история" возникновения этой идеи, мягко говоря, спорна, но исходный смысл ООП подмечен вполне адекватно — дуализм объектов и сообщений: объекты — это то, что может обрабатывать сообщения; сообщение — это объект, которые можно послать объекту для обработки.
и какая от него польза?
Польза… Вопрос интересный. Интересный прежде всего тем, что в такой постановке либо разумно короткий ответ получается либо некорректным, либо бесполезным. Но при этом на него важно ответить. Пока возьму паузу на обдумывание. Возможно, что-то появится в соседней ветке, где я ответил вопросом (так уж получается, это не из плохих намерений) про инкапсуляцию.
…Но, всё же, если очень коротко: дуализм объекты и сообщения дают (как минимум) всё то же, что дают "инкапсуляция–полиморфизм–наследование–абстракция" (то есть последние просто выводятся из этого дуализма), но на гораздо более простом и (для многих) интуитивно понятном уровне; плюс первые имеют больше вариантов реализации.
При попытке продолжить сразу вылезет эта самая инкапсуляция
А вот у меня, знаете, ли никакая "инкапсуляции" ни откуда не вылезает.
Нет, мимо этого и других матных мейнстримовых слов, конечно, не пройти. Но только потому, что их на всех заборах понаписали. Приходится объяснять, что это неадекватные, не отражающие и искажающие смысл исходной идеи слова. Эти слова по какой-то причине были подобранны людьми, которые сами не поняли смысл, но решили донести его до масс. И (вряд ли случайно — тут, очевидно, есть какая-то нехорошая закономерность) таки донесли. По пути и в результате свели к околонулевой вероятности шанс понять эту самую исходную идею без сверхуслий.
Ну, а дальше
…А дальше, чувствую, дискутировать не будет смысла.
У вас уже выстроена некоторая система — трактовка ООП. Она не соответствует исходному замыслу ООП. В ней виден целый ряд несостыковок. Эти несостыковки постоянно вылезают на практике (в данном случае я про себя) и дают повод для критики такого "ООП"… Но, как показывает опыт, в комментариях объяснять и обсуждать это абсолютно бесполезно — пустая трата времени.
Если вас устраивает данная система, она успешно применяется на практике и позволяет успешно создавать программные продуктов — отлично, нет смысла критиковать, раз работает.
Если же не устраивает, и вы ищите (или уже нашли) альтернативы, но никак не хотите (или не захотели) копнуть вглубь и увидеть причину проблем, предпочитаете просто переключиться на другие "парадигмы" и искать "серебряную пулю" (кстати, утверждение "серебрянной пули нет" тоже является "серебряной пулей", не находите?) — тоже ваше дело, не мне вас переубеждать.
Остаётся ещё два возможных варианта.
Либо вы уже копнули, разобрались лучше, чем это прозвучало (выше), но по каким-то причинам не хотите это раскрывать, заставлять не буду.
Если же вы ещё не разбирались или не разобрались, но всё же захотите это сделать — способы найдёте без труда.
А почему бы не объяснять ООП, начиная с …(сюрприз!) ООП? ;)
Там же нет слова "актор". Как нет слов "инкапсуляция", "наследование", "полиморфизм", "абстракция". А вот слово "объект" есть. Может, есть смысл попробовать с него начать?
Парадигма - это "очки", через которые мы смотрим на какую-либо систему.
Это метафора. Вы действительно считаете, что доказывать метафору с инструментами через метафору с очками может быть убедительно?
Откуда следует, что "парадигма" не может успешно покрыть все системы, с которыми вы имеете дело, когда занимаетесь программированием? Да, наверное, объектная и функциональные парадигмы не всегда хороши. Например, строить личные отношения, объективируя или представляя функциями других людей — вряд ли хорошая идея. (Хотя некоторые именно так и делают — и ничего, как-то существуют.) Но это другая область. Что же конкретно ограничивает применимость парадигм в области разработки программных систем?
Я вам ещё мысль подкину.
Как вы считаете, можно ли одну парадигму полностью отразить в другую? Например, в объектной парадигме смоделировать функциональную? И наоборот?
Если вдруг да, то не сводится ли вопрос выбора парадигмы к вопросу выбора языка?
Но в реальности мы вынуждены идти на компромисс.
Бесспорно, но почему? Нас вынуждает ограниченность парадигмы или ограниченность её реализации — в языке, у нас в голове?
Мы можем выбрать одну парадигму, но тогда некоторые части приложения будут невыразительными
А почему они будут невыразительными? Что мешает там, где вам хочется объектно-ориентированного DSL написать его на функциональном языке? Или наоборот?
Я к чему это всё…
Когда IT-индустрия дорастёт до DSL…
Она никогда не дорастёт, если все всегда будут друг другу пересказывать мысль, что "парадигма" это инструмент и её нужно выбирать под конкретную задачу.
Выдвину ещё такую гипотезу.
В идеале, "парадигма" должна отражать способ мышления человека. И вопрос заключается в том, действительно ли у человека есть несколько способов мышления, между которыми он (постоянно) переключается, или же есть некоторая "глубинная" "парадигма", на которую наслаиваются некие "DSL"-и, сформированные в рамках единой "парадигмы" человеческого мышления?
1. Откуда вообще следует это аналогия между (мне не очень нравится термин, но назовём это условно) парадигмой и инструментом?
2. Допустим даже, что есть смысл выбирать парадигму под задачу. Как из этого следует, что смешивать разные парадигмы в одном языке, усложняя его — это хорошая идея?
Тема хорошая и правильная. Но что интересно: и сама статья, и — особенно! — комментарии к ней являются изумительной иллюстрацией к этой теме.
(Не буду говорить про Scrum ` не очень интересно, но, чувствую, с ним та же история.) А с нормальным ООП ни автор, ни комментаторы так и не захотели ведь разобраться! Гораздо проще ведь в очередной раз перемалывать банальную истину про то, что "у каждой технологии есть своя область", не уточняя, где же она находится.
А автор ещё и пропаганду ФП умудрился ввернуть Не совсем беспочвенно, но и не очень-то способствует лучшем пониманию.
А, ну да! Конечно! Теоретические принципы не нужны — вам. Уметь думать не нужно — тоже вам. Ничто, кроме инкапсуляции, не интересует — вас. Почему. А не понимаю — я!
И да, я не понимаю. Например, не понимаю, что вы делаете тут в комментариях по не интересным вам теоретическим вопросам, когда вокруг столько практики для вас.
Почему объяснять ООП через инкапсуляцию — это плохая идея, я, судя по отсутствию рациональных контр-аргументов, показал.
Тратить время на очередной цикл развенчания безосновательных утверждений — как старых, так и постоянно накидываемых новых (включая, к примеру очень показательный пример с предположением — сформулированном как утверждение, и именно в этом-то и проблема; в рассуждениях об ООП она проявляется точно так же — о том, что я не застал Ada) я смысла не вижу.
P.S.: А готовить хотелось бы людей, которые умеют думать, учиться и понимать, что и почему они делают. Тех, кто просто вызубрил "умные" латинские слова, чтобы на бессмысленных интервью ими пробивать себе путь на галеры, а потом жаловаться на то, что их
говнокод"ООП" не работает, и поэтому надо срочно искать другую "парадигму" (чтобы и её так же исковеркать, и, исходя из "практических соображений", деградировать до уровня условной "инкапсуляции" или аналогичног абсурда), и так хватает. Только вот всё идёт к тому, что даже при желании "схоластов" очень скоро готовить будет некому и негде — университеты усиленно сводят к уровню ПТУ. И свою лепту в этот процесс вы тоже вносите ;)P.P.S.: Ещё одно возможное название для данной статьи "Идеи, до смысла которых мы не доросли".
Вспомнился хороший пример…
Был когда-то такой язык — Pascal. У него было множество реализаций. Очень плотно им занималась компания Borland. В какой-то момент — было это в районе 89-го года в Turbo Pascal версии 5.5 — эта компания (на сколько я помню, криво-косо, но таки) начала добавлять в этот язык объектно-ориентированные "фичи".
А до этого, в районе 86-го года в версии 3.0 появились так называемые "модули" (units). Правда в мануале к "тройке" я их описания не нашёл, но в документации к версии 4.0 описано, вроде бы, неплохо.
К чему я это… Модули в Pascal в полной мере реализовывали понятие "инкапсуляция" (в обеих её ипостасях):
Но никакого отношения к ООП ни модули, ни сам язык (на тот момент) не имели. Инкапсуляция есть, а ООП нет.
В ООП состояние объекта — деталь реализации. Его можно решать по-разному, но вот сама концепция от этого не изменится. Суть ООП заключается именно в том, что все вычисления есть результат обмена сообщениями между объектами. Есть состояние у конкретного объекта или нет его — просто-напросто не важно!
Но дело даже не в этом.
Если вводить понятие "инкапсуляция", неизбежно придётся объяснять, что это такое. Для этого придётся вводить другие понятия — как минимум, "данные", "методы"… К тому же, придётся объяснять, что инкапсуляция — это двойственное понятие… И т.д. и т.п. В итоге, понятие "инкапсуляция" будет сложнее, чем понятие "ООП". Но что самое обидное, инкапсуляция сама по себе всё равно не даст понятия об ООП. ООП из инкапсуляции просто-напросто не выводится.
А вот из определения Кэя выводятся и делаются понятными (в контексте ООП) и "инкапсуляция", и "полиморфизм", и "наследование". То есть, если рассказывать, например, студентам, что такое ООП, то сначала лучше рассказать про объекты и сообщения, а потом уже пояснить, что имеют ввиду, когда говорят про трёх-четырёх "китов" ООП. Пояснить и предложить забыть, чтобы не забивать голову ерундой.
Серьёзно? Ну… что ж, очень жаль.
Если желание понять всё же присутствует, возможно вы найдёте что-то интересное и полезное для себя в этом ответе.
Как опытный лектор, могу с уверенностью сказать. что читать лекции сейчас — практически бессмысленное занятие :D
Полностью согласен, что обсуждение любого предмета надо с рассмотрения вопросов "почему?" и "зачем?". Но это же не значит, что можно начинать с чего угодно…
Акторная модель, действительно, имеет — вполне можно сказать — прямое отношение к ООП. Но тогда уж надо рассказывать историю целиком:
как Хьюитт придумал Planner с идеей "бросания" в базу знаний паттерна (вместо прямого вызова процедуры), в ответ на что система сама решала, какие теоремы задействовать;
как Кэй "украл" и положил эту идею в основу Smalltalk-72 (видимо, до него его ещё и в -71, но про него я знаю ещё меньше), что и стало воплощением придуманного им термина "объектно-ориентированного программирования" (sic! — та самая двоица объекты-сообщения);
как потом Хьютт посетил лекцию Кэя и пере-украл идею "вычисления как обмен сообщениями между объектами", но решил, что синхронная обработка сообщений ему не подходит, и запихнул в акторы почтовые ящики для сообщений (кажется, существенно всё усложнив, но тут я не берусь ничего утверждать наверняка).
Если бы модель акторов получила большую известность, чем ООП, смысл начинать с неё, и раскручивать историю в обратную сторону, возможно и был бы. Но про акторы, в отличие от ООП сегодня слышали "не только лишь все, мало кто о ней слышал". Так что, подозреваю, студентов такая логика изложения от очень сложной темы распределённых вычислений и малоизвестной и сложной модели акторов к ООП может только запутать. Но в любом случае это лучше, чем ссылаться "на три кита" ООП.
А вот что действительно могло бы заинтересовать и объяснить, почему и зачем родилось это самое ООП — это рассказ про то, как Кэй в 1968 году придумал "iPad"… Хотя нет, он придумал гораздо более крутую штуку, чем iPad. iPad изначально создавался для потребления. А Dynabook придумывался для созидания. И именно поэтому понадобилась операционная система, которая не просто бы делала для пользователя то, что в неё заложили создатели, а позволяла бы пользователю создавать новую функциональность. А пользователями должны были стать… дети(!) И именно поэтому понадобился (принципиально) новый язык программирования: одновременно максимально простой (что-то типа упрощённого английского) и при этом максимально мощный (способствующий воплощению идей пользователей этого языка). Вот здесь и родилось то самое ООП, которые мы потеряли…
А что именно вы называете моками?
Кто/что вас вынудил/-о? Каким образом?
Что или кто здесь ограничивает применимость "стандартных приёмов"?
Например, кто мешает вместо копипаста портянки под
// Arrangeвынести этот код в отдельный объект и начать формировать удобную в использовании и недублируемую тестовую инфраструктуру для вашей системы?Кто мешает разбить этот тест с пятью условиями (из-за которых вы, по всей видимости, тут же ниже жалуетесь на проверку конфигурации) на 5 разных тестов? Которые, кстати, должны были быть написаны в другом месте, в другое время — потому что к тестируемой функциональности не имеют отношения.
Наконец, кто мешает хотя бы проверку цены после применения скидки записать без дублирования magic numbers?
То есть, переписывать портянку не хотят разработчики?
Отказываются, как следует из контекста, тоже разработчики.
А "провоцируют" и виноваты в конечном итоге моки?
Получается так, что статью следовал бы назвать "О современной разработке. Часть 1: Плохому танцору и моки — это технический долг".
Молоток — это технический долг
Никак не могу оставить в прошлом, одну историю, произошедшую со мной больше 7 лет назад.
На тот момент я, еще студент последнего курса учаги, только получил свою первую шабашку... Осмотревшись по сторонам, понимаю, что кругом меня не то что других молодых нет, но даже разнорабочих. Сплошные дядьки-петровичи с опытом до колена и красными с похмелья лицами... Ну ничего, сейчас я им покажу, что такое «молодая гвардия» 😂.
Получаю спецовку, стакан и струмент. Мне подробнее рассказывают куда что приколачивать. … И на третьем гвозде головка отлетает и отбивает мне большой палец на левой ноге. Я насаживаю головку обратно, и через три гвоздя она опять отлетает и снова отбивает мне большой палец на левой ноге. Больше того, смущает ситуация, что ни у бригадира, ни у кого из мужиков такого не происходит. Молоток стабилен, да и в нем не меняли ничего уже довольно давно. Вывод: проблема на моей стороне и разбираться мне с ней самому.
…
Пытаюсь откопать, от куда этот молоток мог вообще попасть, и сталкиваюсь с суровой реальностью: количество молотков на складе измеряется штуками и все точно такие же — грязные, с перемотанной синей изолентой, растрескавшейся рукояткой, и без клиньев.
…
Молотки, по своей сути, должны быть простым инструментом для забивания гвоздей. Но вместо этого, он становится источником повышенной опасности. Это не нормально, что вместо того, чтоб забивать гвозди, мы чаще смотрим на код, чтоб понять, как работает тест. Сложность насаживания головки и перематывания рукоятки изолентой на столько большая, что мужики стараются забить болт на забивания гвоздей, заколачивая только «там, где нах надо».
Но ведь мы — работяги: мы рождены, чтобы забивать гвозди без боли в большом пальце левой ноги. Почему мы не можем справиться с какими-то гвоздями? Я утверждаю, что проблема в молотках. То как мы вынуждены их заматывать синим скотчем, и следить за полётом головки провоцирует нас делать строгое разделение: вот тут у нас кувалды, где мы стараемся закрепить головку с помощью клина как следует, а вот тут молотки, к которым стандартные приемы не применимы. Тут мы легко сматываем километры синей изоленты, потому что "ну не покупать же новый молоток, он на две бутылки водки потянет, а то и три".
Вы хотите обсуждать здесь личные мнения? Я уже сказал, что не разделяю оптимизма по поводу рациональности этого.
Тем более, что в обсуждаемой статье уже есть ответ на поставленный вопрос:
И, хотя изложенная в статье "история" возникновения этой идеи, мягко говоря, спорна, но исходный смысл ООП подмечен вполне адекватно — дуализм объектов и сообщений: объекты — это то, что может обрабатывать сообщения; сообщение — это объект, которые можно послать объекту для обработки.
Польза… Вопрос интересный. Интересный прежде всего тем, что в такой постановке либо разумно короткий ответ получается либо некорректным, либо бесполезным. Но при этом на него важно ответить. Пока возьму паузу на обдумывание. Возможно, что-то появится в соседней ветке, где я ответил вопросом (так уж получается, это не из плохих намерений) про инкапсуляцию.
…Но, всё же, если очень коротко: дуализм объекты и сообщения дают (как минимум) всё то же, что дают "инкапсуляция–полиморфизм–наследование–абстракция" (то есть последние просто выводятся из этого дуализма), но на гораздо более простом и (для многих) интуитивно понятном уровне; плюс первые имеют больше вариантов реализации.
Если цель — сократить "потенциальную сложность", почему бы тогда вообще не запретить куда-либо обращаться? :)
А вот у меня, знаете, ли никакая "инкапсуляции" ни откуда не вылезает.
Нет, мимо этого и других
матныхмейнстримовых слов, конечно, не пройти. Но только потому, что их на всех заборах понаписали. Приходится объяснять, что это неадекватные, не отражающие и искажающие смысл исходной идеи слова. Эти слова по какой-то причине были подобранны людьми, которые сами не поняли смысл, но решили донести его до масс. И (вряд ли случайно — тут, очевидно, есть какая-то нехорошая закономерность) таки донесли. По пути и в результате свели к околонулевой вероятности шанс понять эту самую исходную идею без сверхуслий.…А дальше, чувствую, дискутировать не будет смысла.
У вас уже выстроена некоторая система — трактовка ООП. Она не соответствует исходному замыслу ООП. В ней виден целый ряд несостыковок. Эти несостыковки постоянно вылезают на практике (в данном случае я про себя) и дают повод для критики такого "ООП"… Но, как показывает опыт, в комментариях объяснять и обсуждать это абсолютно бесполезно — пустая трата времени.
Если вас устраивает данная система, она успешно применяется на практике и позволяет успешно создавать программные продуктов — отлично, нет смысла критиковать, раз работает.
Если же не устраивает, и вы ищите (или уже нашли) альтернативы, но никак не хотите (или не захотели) копнуть вглубь и увидеть причину проблем, предпочитаете просто переключиться на другие "парадигмы" и искать "серебряную пулю" (кстати, утверждение "серебрянной пули нет" тоже является "серебряной пулей", не находите?) — тоже ваше дело, не мне вас переубеждать.
Остаётся ещё два возможных варианта.
Либо вы уже копнули, разобрались лучше, чем это прозвучало (выше), но по каким-то причинам не хотите это раскрывать, заставлять не буду.
Если же вы ещё не разбирались или не разобрались, но всё же захотите это сделать — способы найдёте без труда.
А почему бы не объяснять ООП, начиная с …(сюрприз!) ООП? ;)
Там же нет слова "актор". Как нет слов "инкапсуляция", "наследование", "полиморфизм", "абстракция". А вот слово "объект" есть. Может, есть смысл попробовать с него начать?
Видимо, дитя ООП внебрачное?
BlockClosure>>#whileTrue: aBlockself value ifTrue: [ aBlock value. self whileTrue: aBlock ].^ nilКонечно, поздновато комментировать, надо было сразу… Но всё же скажу:
Может быть всё же не идеи потеряли смысл/суть, а "мы" (в статистическом смысле) "потеряли" смысл и суть этих идей?
Это метафора. Вы действительно считаете, что доказывать метафору с инструментами через метафору с очками может быть убедительно?
Откуда следует, что "парадигма" не может успешно покрыть все системы, с которыми вы имеете дело, когда занимаетесь программированием? Да, наверное, объектная и функциональные парадигмы не всегда хороши. Например, строить личные отношения, объективируя или представляя функциями других людей — вряд ли хорошая идея. (Хотя некоторые именно так и делают — и ничего, как-то существуют.) Но это другая область. Что же конкретно ограничивает применимость парадигм в области разработки программных систем?
Я вам ещё мысль подкину.
Как вы считаете, можно ли одну парадигму полностью отразить в другую? Например, в объектной парадигме смоделировать функциональную? И наоборот?
Если вдруг да, то не сводится ли вопрос выбора парадигмы к вопросу выбора языка?
Бесспорно, но почему? Нас вынуждает ограниченность парадигмы или ограниченность её реализации — в языке, у нас в голове?
А почему они будут невыразительными? Что мешает там, где вам хочется объектно-ориентированного DSL написать его на функциональном языке? Или наоборот?
Я к чему это всё…
Она никогда не дорастёт, если все всегда будут друг другу пересказывать мысль, что "парадигма" это инструмент и её нужно выбирать под конкретную задачу.
Выдвину ещё такую гипотезу.
В идеале, "парадигма" должна отражать способ мышления человека. И вопрос заключается в том, действительно ли у человека есть несколько способов мышления, между которыми он (постоянно) переключается, или же есть некоторая "глубинная" "парадигма", на которую наслаиваются некие "DSL"-и, сформированные в рамках единой "парадигмы" человеческого мышления?
А речь вообще не о выборе языка под задачу.
Здесь возникает по крайней мере два вопроса:
1. Откуда вообще следует это аналогия между (мне не очень нравится термин, но назовём это условно) парадигмой и инструментом?
2. Допустим даже, что есть смысл выбирать парадигму под задачу. Как из этого следует, что смешивать разные парадигмы в одном языке, усложняя его — это хорошая идея?
А что в этом прекрасного?
Тема хорошая и правильная. Но что интересно: и сама статья, и — особенно! — комментарии к ней являются изумительной иллюстрацией к этой теме.
(Не буду говорить про Scrum ` не очень интересно, но, чувствую, с ним та же история.) А с нормальным ООП ни автор, ни комментаторы так и не захотели ведь разобраться! Гораздо проще ведь в очередной раз перемалывать банальную истину про то, что "у каждой технологии есть своя область", не уточняя, где же она находится.
А автор ещё и пропаганду ФП умудрился ввернуть Не совсем беспочвенно, но и не очень-то способствует лучшем пониманию.
Если в голове у ФП последователей такое, я прохожу мимо 😆