Комментарии 63
"Это другие обьекты" )
А то, о чем вы говорите - вас сейчас тапками закидают, потому что у вас "тип посылки заранее не определен", а сейчас в моде "типизация": ваша посылка в почтовый ящик не пройдет, потому что этот ящик строго под определенную форму посылки.
Ну, ограничения всегда есть, понятно, что автомобиль посылают какой-то другой почтой...
Хм, вообще в ООП как раз тип сообщения - известен. ООП (еще со времен smalltalk) про объединение данных и методов с ними работы. Методы работы - да, можно описывать как отправку сообщений. Важно, что у конкретного объекта известно, какие сообщения он может принимать и при отправке - не важно и даже не известно, как именно они будут обрабатываться.
IoC - это поздний паттерн, ООП может быть и без IoC.
Смешались в кучу люди-кони. Мне кажется вы спутали, принципы ООП с паттернами проектирования. Обмен сообщениями, позднее связывание и инверсия зависимовстей, это замечательные и полезные вещи, которые хороши там, где нужны. Но при всем уважении, они никак не являются основными принципами ООП.
К слову, вы пишете:
Но современное поколение, в основной своей массе, почему-то считает, что ООП - это что-то новое, и к тому же неудачное, и поэтому его надо срочно заменить чем-то типа Питона или на худой конец Скалы итп.
Не понятно, почему вы противопоставляете ООП и Питон со Скалой? Это вообще сравнение теплого с мягким.
Это примеры из реальной жизни, а не моя выдумка. Есть даже статьи на уважаемых порталах типа Medium, где пишут, что от ООП надо отказываться и переходить на Питон и тп. И пишут вроде бы специалисты с аргументами.
Я ничего не спутал, я говорю о принципах, которые при определенном взгляде могут стать паттернами. Паттерн - это способ решения похожих задач, этим словом можно обозвать вообще все...
"Новым поколением" автор согрел мне душу. Я-то уже давно чувствую себя старым :)
Вот это правильная статья про ООП
Я ещё позволю себе добавить, что ООП есть воплощение общеинженерного принципа декомпозиции и убежать от него никуда не получится. Хотя бы по той причине, что мы, люди, думаем объектами
Когда я изучал Паскаль, мне казалось, что люди думают по-шагам. Когда я изучал Джаву, казалось, что люди думают объектами. Когда SQL, казалось, что удобнее всего думать, отдавая приказы другим. Когда ознакомился с Прологом, казалось, что люди думают фактами, а когда с Хаскелем, что люди думают функциональными зависимостями. А на самом деле никто не знает как думают люди, скорее всего они думают по большей части чувствами и эмоциями и немножко всеми вышеперечисленными способами.
По-моему, основной принцип ООП — это уменьшение сложности коллективного программирования любым путём, оставаясь в рамках текстовой нотации. Там, где сложность программирования ещё подвластна одному человеку, ООП по-прежнему успешно игнорируют.
Например, в малых встраиваемых системах. Вот буквально вчера увидел анонс от STMicroelectronics (ST) о том, что они перевели свою библиотеку по управлению моторами с C++ на C, и это значительно упростило её (с их слов).
Таки переход от с++ к си не означает отказа от ооп. Как известно, эталонное применение ооп, vfs ядра линукс - это вполне себе бодрый си
Всякая вещь, будучи применена на своем месте, неминуемо приносит пользу (с) К.Прутков, 19 век
К сожалению люди часто любят приводить всё к одному знаменателю, запихивая ООП (то, которое с классами-наследованием-полиморфизмом) туда где оно нафиг не нужно.
Давайте зацепимся за эту мысль.
По сути у нас есть две разных сущности с одним названием.
Есть ООП как "Средства поддержки ООП" - это вот про классы, инкапсуляцию, композицию , полиморфизм и прочее.
А есть ООП как парадигма, как способ мышления и филосовский инженерный принцип
И это конечно же не одно и тоже. Тем не менее, по устоявшейся традиции и то и другое называется ООП
Однако ООП плохо гармонирует с требованиями реального времени во встраиваемых системах.
Сообщения между объектами — настоящее зло в системах реального времени. Для сообщений необходимо создавать очереди. Наполняемость очередей и их задержки нужно как-то оценивать, затем тестировать. И всё равно остаётся страх, что очереди переполнятся или приведут к недопустимым задержкам. Проще создавать жёсткие автоматы состояний с иерархией, без использования структуры программы в виде объектов.
Теперь автоматы часто создаются в графической нотации. А графическая нотация позволяет реализовать гораздо более сложную логику, чем текстовая. То, что раньше решалось с помощью текстового ООП, теперь может быть реализовано автоматами в графической нотации.
Симуляция, которая была одной из причин появления ООП, также перешла в графические среды. Всё меньшему числу людей необходимо знать о парадигме ООП.
Вообще для отправки сообщений не нужны никакие очереди, сообщения могут отправляться (и обрабатываться) и мгновенно (как в http или в том же Smalltalk).
ООП никак не противоречит системам реального времени, более того, активно в них используется.
Тут у вас довольно много всего написано и тут есть что сказать.
Действительно, софт реального времени требует оптимизаций и специфического консенсуса между возможностями железа и математической стройностью. Во время оптимизации кода в бой бросаются специальные частные средства заточенные под вполне конкретный случай. Оптимизация всегда предполагает отход от парадигмы, какой бы она не была. Собственно поэтому и существует правило согласно которому оптимизация выполняется в последнюю очередь. Да, действительно, во многих приложениях декомпозиция, лежащая в основе ООП, вступает в конфликт с принципами работы кеша современных процессоров. Это сложно не заметить. Практика показывает, что оптимизации по быстродействию требуются, но требуются в довольно ограниченной области программы, в то же время хорошо декомпозированный код довольно легко транспонируется в оптимизированную форму, поэтому проблема эта разрешима
Что касается сообщений, я вообще говоря, считаю, что Алан Кей ошибался. Большая идея -это как раз таки объекты, а как они между собой связаны - дело десятое. Были попытки делать языки с трушным обменом сообщениями. Было грандиозное противостояние микроядерной и монолитной архитектур ОС, ярко выразившееся в мемной переписке Торвальдса и Таненбаума. Практика показала, что с настоящими сообщениями и без них получается один фиг, но без сообщений проще. К сообщениям между объектами следует относиться как к матмодели, хорошо приближающей то, что происходит в абстрактном объектном пространстве при вызове метода, но не более
Что касается графической нотации, на этот счёт существует консенсус. Графические языки это хорошо и правильно. Многие алгоритмы в них выглядят очень приятно. Кроме того существует возможность визуализации промежуточных вычислений. Это архиприятно, когда речь идёт, к примеру, о шейдерах. Шейдеры вообще отлично ложаться под графическое программирование. Тем не менее, существует потолок сложности, после которого граф становится неподдерживаемым. Читать и отлаживать программы написанные на графике сложно, поэтому не стоит ожидать, что человечество когда-то перейдёт на графику полностью. Ну и уж точно потоковая обработка графами никак не пересекается с теми сферами в которых доминирует ООП. Графы конкурируют, а на самом деле дополняют реактивную парадигму. И кстати, при манипуляциях над конвеером в рамках какого нибудь gstreamer становится очевидно, что обращаться с частями конвеера надо как с объектами. Никуда от этого не деться
А что до симуляции объектов реального мира, это пусть люди которые это придумали закопают это там, откуда они это взяли. Объектом в программировании могут быть функторы, алгоритмы, транзакции, даже ничто может быть объектом. Вот когда автор тезиса про объекты реального мира придъявит мне ничто как объект реального мира, вот тогда поговорим на эту тему
Графика как и ООП в смысле нотации нужны для одной и той же задачи - упростить программирование на верхнем уровне.
Самый низкий уровень по прежнему пишут на ассемблере, повыше на C и уже на верху C++ и скриптовые движки.
Появление ИИ заморозит эту схему, надобности в новых языках для упрощения ассемблера или С уже нет.
Потом графическая нотация все время совершенствуется.
Я лично считаю неудобными такие движки как Node-RED, Unreal Engine Blueprint, Labview, но считаю очень удобным движок Stateflow в MATLAB. С графами Stateflow роднят только стрелочки, а больше ничего общего.
ООП как парадигма - это просто калька со здравого смысла.
Вот пункты этой парадигмы: фокус на объектах, модульность, повторное использование, удобство моделирования.
Любой адекватный программист будет делать программу модульной, будет делать шаблоны или заготовки, будет копировать взаимодейcтвия окружающего мира. Что тут такого уникального в этой парадигме? Какие могут быть альтернативы?
Нет, ООП - это прежде всего нотация, остальное от лукавого.
Или давайте трансформеров в ИИ обзывать ООП.
Когда-то революционной была идея процедуры. Вместе с ней появилось процедурное программирование. Но сегодня никто не считает процедурное программировпние чем-то интересным, потому что здравый смысл велит писать код процедурно. Потом пришёл дийкстр и потрясая теоремой Бёма-Якопини изрёк, что код надо писать структурно. Так родилась идея структурного программирования, но сегодня никто не скажет, что струетурное программирование это интересно, потому что все пишут код структурно.
Да, писать код объектно буквально означает "писать код в соответствии со здравым смыслом". Сегодня даже те, кто воюет против ООП пишут код объектно просто потому что они воспитывались в среде, где все пишут объектно и впитали эту идеологию "с молоком матери"
Писать код объектно, значит объединить процедуры с данными так, чтобы работа процедуры неявно зависла от состояния данных. Насколько эта идея соответствует или противоречит здравому смыслу вопрос открытый. Конечно, так писать код немножко проще - не надо заботится о том, чтобы передавать в каждую процедуру весь необходимый набор входных аргументов, а все нужные ей данные будут переданы неявно. То же и с выходными данными.
Писать такое немножко проще. А тестировать? Гораздо тяжелее. Ну если у вас есть куча тестировщиков, которые каждый написанный вами метод протестируют вдоль и поперек, при всех возможных комбинациях значений состояния данных в объекте, тогда несомненно только так и надо делать. Если же с неба дождь из тестировщиков не льётся, то уже не факт, что методы были хорошей идеей.
Писать код с неявной передачей аргументов и неявным возвращением значений удобно, но какой ценой даётся это удобство? Всё равно по факту все эти неявные параметры приходится учитывать в голове, постоянно о них думать - а какое там состояние у объекта, а точно ли метод отработает так, как я предполагаю, или возможно состояние, при котором логика работы нарушится? Это требует постоянной концентрации внимания и очень сильно изматывает. А за длительное время приводит к выгоранию. Конечно, всё можно решить 100% покрытием юнит тестами, но времени на исчерпывающее написание тестов бизнес не даёт - подгоняет. Да и писать юнит тесты, которые будут учитывать все возможные состояния данных объекта это задача высокой комбинаторной сложности. А потому все приходится делать за счёт повышенной собранности и максимальной концентрации внимания. По себе замечал, что из всех парадигм программирования, ООП подход изматывает нервную систему сильнее всего.
Прикольная ирония. Плюс в карму.
Я вижу тут парадокс яйца и курицы.
Да, верно. К примеру, LabVIEW позволяет "писать" программы как для компьютера без единой строки кода. Только диаграммы и связи. Я и мой коллега очень успешно применяем связку LabVIEW c SQL, что позволяет разрабатывать сложные приложения автоматизации производственных процессов. Одну из таких систем я описал в своей статье на Хабр.
При переходе на C придется забыть про хэш-таблицы: "Библиотеки от проекта GNOME, которые написаны в парадигме gobject - это г... лютое, там на каждый чих по 10 аллокаций памяти, и линейный перебор по куче связанных списков.
А все потому, что в С еще не изобрели хеш-таблицу".
Мое мнение что главная проблема современного ООП что никто толком даже не понимает что это вообще такое. Все есть объект? Если взять столпы ООП в виде C++ и Java, там все есть объект? Нет. Инкапсуляция, наследование, полиморфизм? Прекрасно существуют и в не ООП языках и не делают их ООП языками.
По моему личному мнению, современное ООП это не целостная самодостаточная концепция с четкой теоретической базой, целями, задачами и путями их решения. Современное ООП - это просто одно из направлений развития старого доброго структурного программирования к которому добавили идею еще одного уровня модульности (на уровне структуры) и прикрутили несколько свистоперделок в виде наследования типов и динамической диспетчеризации а также назвали это модным по тем годам словом.
Именно по этому, за несколько десятилетий так и не научились как на нем правильно писать а эволюция написания ООП программы пришла к простому процедурному стилю, где нужно иметь тупые объекты только с данными и сервисы без состояния.
Если взять столпы ООП в виде C++ и Java
Возьмите всё таки Smalltalk. В С++ и Java в приоритете практические соображения, а не чистота концепции.
Использую пример Smalltalk в дискуссиях с апологетами ООП. Но большинство видит ООП как оно преподносилось в Java/CPP, основываясь на ”Чистом коде” Боба Мартина. Радует, что коммьюнити начинает осознавать, что ООП — не волшебная таблетка, что SOLID — набор случайных принципов (хватит молиться на solid), DRY не надо злоупотреблять, потому что он не бесплатный (нарушение LoB). Cкажи я всё то же саамое 7-10 лет назад — подозреваю, что меня бы живьем съели и статус “отхабренный“ повесили.
не сыпьте бисер перед свиньями. Свини красоту бисера не смогут оценить.
Мне кажется, тут суть в другом.
Изначальная идея ООП - это объединить данные и методы их обработки в некую единую сущность - объект. Для своего времени идея была прорывная: позволяла скрывать реализацию и выставлять наружу простой интерфейс, выносить общий код в родителя, и все такое, чем знаменито ООП. И не сказать, что оно плохо работает, тот же гуй на ООП вполне себе ложится.
Потом научились делать многоядерные процессоры и ВНЕЗАПНО оказалось, что объекты с мутабельным стейтом очень плохо ложатся на многопоточность. Ну и, почесав репу, умные люди решили данные и методы разделить, но на качественно ином уровне: пусть у нас будут глупые данные (в идеале немутабельные) отдельно и функции для их обработки (в идеале чистые) отдельно. Получилось вполне неплохо: отлично параллелится и векторизуется, очень удобно писать автотесты. Модный реактивный поход тоже залетел.
В итоге каждый подход хорош в своей области. Многие языки поддерживают оба похода, и это хорошо: UI с окошками и формочками удобнее писать на ООП, а обрабатывать данные с бэка, фильтровать, форматировать и байндить на UI удобнее функциональщиной. А когда пытаются натянуть одно на другое - начинаются непонимания, конфликты, боль и страдания.
Это как ОТО и квантовая механика: каждая неплохо работает в своих границах применимости, а если попытаться натянуть одно на другое - фигня получается. Ученые пытаются разработать Единую Теорию Всего - пока выходит не очень, но кто знает. Глядишь, и в программировании изобретут подход, сочетающий преимущества ООП и функциональщины.
Цитаты Алана Кея - отца ООП, которые "в тему" статьи:
Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++.
Я жалею, что придумал термин «объекты» много лет назад, потому что он заставляет людей концентрироваться на мелких идеях. По-настоящему большая идея — это сообщения.
Ключ к тому, чтобы делать большие и расширяющиеся системы, заключается в том, чтобы придумывать, как модули будут общаться друг с другом, а не заботиться об их внутренних свойствах и поведении.
Немного странные комменты. Я пытался рассуждать об идеологии, но комментаторы почему-то сваливаются в реализации. Если говорить о конкретных языках, то большинство из них обладает одним и тем же недостатком - статические сигнатуры методов для обработки сообщений. А идея в том и состоит, чтобы сообщения были максимально произвольные. Некоторые утверждают, что бывают кейсы, в которых структура сообщения вообще неизвестна.
На протяжении последних 50 лет развитие программирования идёт в том направлении, чтобы каждый кусочек программного кода давал разработчику как можно меньше свободы - только лишь чтобы выполнить в этом куске кода минимальное необходимое действие и ничего больше. Как показывает практика, при таком подходе возникает меньше ошибок, и меньше уязвимостей, и проводить рефакторинг такой системы гораздо проще. А что хорошего в том, чтобы сообщения были абсолютно произвольные? Например, чтобы была возможность передавать в сообщениях произвольный исполняемый код или sql инъекции?
программирование развивается в разных направлениях... код - это не сообщение, код сам обрабатывает сообщения. Речь идет о блэкбоксах. ЧТоб было понятно, давайте пофантазируем. Вот у нас есть пос-терминал, он может обработать: visa, mastercard, jcb и даже Американ Экспресс... уже какая-то степень произвольности достигнута, причем, когда мы платим, мы вообще не задумываемся, сколько там всего происходит... А вот есть еще средство платежа, как наличные или еще того круче - криптовалюта! - и уже этому пос-терминальчику слабо, не умеет он такие сообщения обрабатывать. Но ведь нам нужно сделать то же самое действие - заплатить. Т.е. повернуться надо лицом к человеку! а не к компьютеру. Вы все заботитесь о том, как систему создать, а нужно беспокоиться о том, какие сообщения приходят в систему. Но рассуждать о таких вещах в эпоху роботов и ИИ более, чем странно.. Я просто хочу, чтобы мне про ООП вопросы не задавали.)))
Нет никакой произвольности на POS-терминале. Там есть очень жесткий протокол, все возможные обработки которого (для VISA/MC/etc) жестко описаны. Нет возможности в POSе использовать вместо банковской карты - какую-то другую (например, телефонную).
В реальном мире (и в проектировании) как раз сообщения, которые может обработать объект - всегда жестко специфицированы. И ООП - как раз про это.
Даже странно об этом писать... pos-terminal - это всего лишь считыватель информации, а протокол общения с системами оплаты там тот, который вы в него заложите, и жестким он будет именно настолько, насколько жестким вы его сделаете... даже странно это объяснять.. Считанная информация может проходить через несколько систем с разными протоколами, а сама оплата произойдет на 5-й ступени неизвестно где.... Вы не хотите думать... Блэкбоксом здесь является ваша программа, которая обрабатывает считанную терминалом информацию. А терминал можно сделать, что он будет считывать криптокошельки или принимать доп. ввод инфы ..... Все ваши заявы только подверждают отсутствие понимания ООП и принципа Message Passing. А уже не говорю про то, что вы там про IoC - там не о чем говорить, настолько там все очевидно.
Pos терминал имеет дело с конкретным форматом записи на карте (чип), поддерживает сложный протокол для работы с этим чипом (ISO 8583, загрузка ключей, работа с сеансами и так далее). И без этой жесткой логики, описывающей сообщения как от эквайера к POS, так и взаимодействие POS и карты - никакие платежи по карте невозможны. При этом весь обмен от банковской карты и до банка-эмитента жестко описаны документацией в несколько тысяч страниц.
И, в рамках ООП, карта, POS, софт эквайера, софт эмитента, софт ПС - как раз объекты, обменивающиеся сообщениями. При этом форматы (типы) сообщений жестко описаны, а вот сама логика - да, может быть очень гибкой. Собственно, в этом и есть смысл ООП
2. Кажется, вы не понимаете не только принципы работы POSов, но и ООП и процессы передачи сообщений. Благо уж по ООП много литературы и там описано и что такое сообщение и что такое объект.
Собственно, о том, что вы не очень разбираетесь в ООП - уже написало довольно много человек.
насчет много человек - не аргумет, мнение толпы чаще всего ошибчно, и апеллировать к толпе - это путь плохого человека.. И при чем здесь формат записи? Надо исходить из того, что у вас есть какое-то средство оплаты и вам нужен объект, которому надо передать сообщение об оплате - все. А вы мне про какие-то реализации... может быть ISO 8583, а может что-то другое... а может это вообще никому не надо... В таком случае программирование сводится к тому, что вы должны думать, что делать с этим сообщением об оплате, а не о том какой протокол использовать для обмена фин. информацией. Если вы будете ориентироваться на сообщения, вы будете как-то иначе строить приложения для процессинга. А вы с самого начала загоняете сообщения в жесткие рамки, диктуете, какой должен быть формат, и как можно более жесткий формат, по вашим же понятиям.
Но самое главное, что дверь уже давно открыли, и проблемы эти давно решены.
пс тут кто-то из толпы пишет, может даже вы, что отцы основатели ООП вообще лохи позорные, тоже не понимают, что такое ООП, и вот только обитатели хабра....
я помню по молодости, когда общался с бизнесом, тоже объяснял им, что я не смогу ничего обработать, если мы четко не договоримся о формате сообщения, что все должно быть жестко формализовано итп. А они не понимали, почему нельзя сделать гибко. И в конечном итоге выяснялось, что такое жесткое приложение мало кого заинтересует. А потом и мне становилось ясно, что надо искать другие пути.
Хм, похоже, вы просто не понимаете, что такое POS. Он не отправляет никакой информации об оплате. Процесс оплаты вообще происходит довольно далеко от POS. Лучше не использовать примеры из областей, в которых не разбираетесь.
Я не очень понимаю, откуда взялось противопоставление "сообщений" и "формата". Сообщения - всегда в каком-то конкретном протоколе, в конкретном формате и содержат конкретную семантику. И ООП, в том числе, и об этом. И как раз про это и пишут основатели ООП.
Очень странная идея. Идея как раз в том, что для объекта известно, какие именно сообщения он может обрабатывать, но не известно, как именно. Если структура сообщения неизвестна получателю, то как он может его обработать?
Как известно, единственный язык (из широко используемых в индустрии), реализовавший идеи Кая по части сообщений (акторную модель) — это эрланг. Довольно забавно, кстати, что его пока вообще никто не упомянул.
Так вот в эрланге, в полном соответствии с оригинальной концепцией, объекту (процессу) можно послать любое сообщение. Более того, существует концепция abcast — типа бродкаст. Если процесс не умеет такое сообщение обработать — он его проигнорирует (точнее, виртуальная машина проигнорирует, но это детали).
И, конечно же, весь обмен сообщениями — в принципе асинхронный. Синхронно получить ответ из коробки — невозможно (но есть абстракции, наподобие загадки про передачу ключа в коробке с двумя замками).
При этом, что забавно, Erlang не называет себя объектно-ориентированным. И "отправить любое сообщение" - это не значит, что сообщения не типизованы и нет контрактов. И в эрланге и в смолтолке типы есть, разница только во времени проверки - при компиляции или при исполнении.
Ну и заметим, что актор - обычно несколько больше чем объект.
это не значит, что сообщения не типизованы и нет контрактов
Да нет, ровно это и означает. Любой эрланговский term подойдет.
актор — обычно несколько больше чем объект
В эрланге — это процесс. Не знаю, больше он, чем объект, или нет.
Ну, если уж совсем занудствовать,
то любой term подойдет внутри message, а так-то типизация сигналов очень даже есть (message/link/etc). Впрочем, системные сигналы можно и не считать
Набор матчингов в recieve - это как раз контракт процесса и определяет, какие сообщения он может получать. Отправлять другие сообщения - бесполезно.
То, что типизация сообщений идет на pattern matching, а не на RTTI - не принципиально, все равно это про контракт и сообщения.
В эрланге у процессора дофига всякого (несколько очередей, например). Это точно несколько больше, что то, что обычно считают объектом.
Но это все, конечно, мелочи )
Ну и хотя акторные системы (среди которых далеко не только Эрланг) и являются примером ООП, но ООП не исчерпывается только акторами или только Эрлангом.
Я пытался рассуждать об идеологии, но комментаторы почему-то сваливаются в реализации.
Потому что программы пишуться на реализации конкретных решений а не на идеологии. Большого смысла рассуждать как было бы хорошо если бы... нет.
Если говорить о конкретных языках, то большинство из них обладает одним и тем же недостатком - статические сигнатуры методов для обработки сообщений.
Наверное потому что методы это не обработчики сообщений а методы.
А идея в том и состоит, чтобы сообщения были максимально произвольные. Некоторые утверждают, что бывают кейсы, в которых структура сообщения вообще неизвестна.
А что в этом такого сакрального и зачем вам это именно в ЯП? Хотите построить архитектуру где обработчики будут получать сообщения и произвольно обрабатывать их, напишите. Вот есть акторные модели есть архитектурное модели такого построения.
Вот у меня сейчас на проекте именно такая - микросервис получает сообщение через кафку и обрабатывает только те которые знает, остальные игнорирует. Что это такого даст если это внедрить на уровень ЯП?
Я думаю что ваша интерпретация так же не верна, как и классическое "инкапсуляция, полиморфизм, абстракция".
Концептуальная идея крайне проста - сложную систему нужно разбить на автономные части с данными(объекты), которые взаимодействуют друг с другом через сообщения.
Вот и все.
Из этого следуют многие полезные свойства - объект может контролировать целострость своих данных, код и данные по обработке локально сконцентрированы, их удобнее читать. Код легче переносить, потому что объекты связаны только через сообщения. И т.д.
В целый ряд парадигм этому неплохо соответствует. Языки, которые были написаны на основе этой идеи, реализовали их через разные инструменты - классы и объекты как продвинутые методы структур, слитых с методами, методы как типизированные сообщения, интерфейсы и полиморфизм для абстракции сообщений (то самое, что нужно знать про сообщение, а не кто и почему его обрабатывает), наследование как вспомогательный механизм организации. Многие языки буквально поддерживают сообщения.
Развитие этих языков привело к тому, что сейчас все больше сосредотачиваются на инструментах, чем на концепте.
Это не лишено смысла, потому что на этом велосипеде в любом случае нужно научиться ездить.
Но суть немножко теряется.
В этом смысле то, как мы используем объекты в классических языках - это не объекты, о которых говорил Кей, это их запчасти.
В общем кажется, что это и приводит к всему трешу вокруг этого вопроса.
Концептуальная идея крайне проста - сложную систему нужно разбить на автономные части с данными(объекты), которые взаимодействуют друг с другом через сообщения.Вот и все.
Это верно, но вы почти что скопипастили фразу из моего текста... и я не против.
У вас есть подобное, просто суть в том, что вот эта идея вот так проста на самом деле.
Нужно еще понимать контекст, когда она появилась, идеи о структурном программировании были еще новы, люди руками в памяти копались, а хаки типа глобальных переменных были не то что не плохой практикой, а, так сказать, стандартной архитектурой.
В остальном проблем с паттернами, SOLID, инкапсуляцией и полиморфизмом и прочим нет. Это действительно хорошие инструменты со своими областями применения.
письма любого типа: закзаные, открытки, микро бандероли …. типа того..
Вот это самый обычный полиморфизм. Все перечисленные вами типы отправлений имплементируют один и тот же интерфейс, в котором подразумевается наличие как минимум адреса получателя и марки. Конверт без адреса или конверт без марки не будет обработан. Равно как не будет обработан любой другой предмет, попавший в ящик, но не имплементирующий интерфейс почтовой корреспонденции. И как видите, типизация тут абсолютно ярко выражена.
На мой взгляд, ооп это просто абстрагированное описание моделей и их свойств некоего создаваемого вами виртуального мира, называемого программой, для компьютера. Не нужно забывать что это просто модели для отображения пикселей на экране монитора, смартфона и т п. В общем случае это паттерн имхо. Создавать программы это не к ооп, это к архитектуре и декомпозиции задачи. Далее выбор паттерна, имхо. И лучше не так как проще, а так как реальней, стабильней, быстрее и дешевле. Все зависит от задачи. И не всегда ооп нужен.
Я за годы программирования на Smalltalk привык, что ООП - это когда объекты реального мира отображаются на объекты в коде. Этот подход прост и достаточно хорошо работает по моему опыту.
При этом не обязательно посылка сообщения должна быть. Когда объект в реальном мире взаимодействует с другим (например прикасается или давит на другой), он не посылает сообщений. Технически, программно можно вызвать метод или занести значение в публично доступное поле объекта.
Есть ещё такой вопрос: а действия могут быть объектами? А то я часто встречаю когда их упаковывают каждый в отдельный сервисный класс.
Технически, программно можно вызвать метод или занести значение в публично доступное поле объекта.
В Smalltalk вроде как сообщения вместо методов и все поля данных приватные.
Я не про Smalltalk говорил.
Про посылку сообщения я говорил относительно статьи, где указано, что это один из основных принципов ООП. Мне кажется, что объектам не обязательно слать друг другу сообщения. Можно и по другому взаимодействовать. И при этом объекты останутся объектами и программирование будет объектно-ориентированным и дальше.
В моём понимании объекты на первом месте. А то, как они взаимодействую, это уже каждый выбирает сам.
Если действие можно вызвать, то это просто вызов действия объекта которому оно относится. Например можно программно нажать кнопку.. Но это не объект.
Что такое ООП (объектно-ориентированное программирование)