Тут вот какое дело, понимаю, что написаны тысячи, если не миллионы, книг и статей на тему... Сам я безработный разработчик предпенсионного возраста, нахожусь в поиске, и меня, хотя и редко, но приглашают на собеседование, где меня обязательно спросят про "основные принципы ООП", чем всегда ставят меня в тупик, я не знаю, что отвечать на этот вопрос.
Когда-то, лет 30 назад, мне посчастливилось поработать в одном очень продвинутом коллективе известного ВУЗа, и там один из научных руководителей регулярно приходил в бешенстве с конференций, на которых обсуждались видения ООП и подходы к реализациям, потому что его понимание сильно отличалось от коллег-участников конференций с других кафедр. Кстати сказать, он написал java-подобный язык, который вроде до сих пор с успехом используют. Этим воспоминанием я хочу подчеркнуть, что проблема не такая уж и новая, и не такая уж и надуманная.
В современных источниках об ООП-принципах вы непременно найдете тезис об инкапсуляции, наследовании и полиморфизме, тогда как на заре компьютерных наук ни один из разработчиков или компьютерных ученых ничего подобного вам бы не заявил. Наверняка здесь есть какая-то путаница.
Ну, посудите сами, парадигмы процедурного программирования основанные на теореме структурного программирования окончательно сформировались только к началу 70-х годов прошлого века, а первые языки ООП появились еще в начале 60-х годов. Но современное поколение, в основной своей массе, почему-то считает, что ООП - это что-то новое, и к тому же неудачное, и поэтому его надо срочно заменить чем-то типа Питона или на худой конец Скалы итп.
В этой связи встает вопрос: как же компьютерные ученые, разработчики первых языков ООП, представляли себе постановку задачи, и вообще, что это такое ООП?
Идея состояла в том, что мы в реальном мире каким-то образом манипулируем объектами, и пришли к выводу, что все, что мы для этого делаем - мы передаем сообщения объектам, и самое интересное, что нам совершенно все равно, что там дальше происходит с этим сообщением, но мы уверены, что оно будет обработано и нами будет получен результат обработки. Тогда ученые и задумались, как бы нам создать такие языки программирования, чтобы и в виртуальной среде можно было решать задачи используя подобный подход.
Например, когда еще не было электронной почты (многие даже не представляют, что такое было), люди писали письмо другу на бумаге, потом запечатывали его в конверт, писали на конверте адрес получателя и отправителя, потом несли конверт к почтовому ящику, опускали его туда, и ждали результат - либо "доставлено", либо "возврат отправителю". В данном примере мы имеем дело с объектом "почтовый ящик", мы передаем ему сообщение - опускаем письмо, другими словами: вызываем метод Result postBox.send(Letter letter);
Это и есть первый принцип ООП — он так и называется: Message Passing.
Нам абсолютно все равно, какие действия будут совершены после того, как мы опустим письмо в ящик, а их невероятно много: придет почтальон и заберет все письма из ящика, на почте отсортируют, отвезут к правильному самолету и тд, и тп.
Дальше нам бы хотелось, чтобы почтовый ящик был таким, что в него можно было бы опускать письма любого типа: закзаные, открытки, микро бандероли …. типа того.. И мы бы не соверашали дополнительных действий, а просто бросали письмо любого типа в один и тот же ящик и ни о чем не задумывались, не задумывались, как этот ящик будет обрабатывать разные типы. Т.е. на этапе создания почтового ящика мы не знаем какого типа письма будут в него опускать, ящик должен уметь обрабатывать любой тип письма без дополнительных на то уведомлений.
Переходя к программированию мы говорим, что на этапе компиляции тип объекта сообщения нам неизвестен, а узнаем мы этот тип только в рантайме — этот принцип ООП называется Late Binding, а никакой не полиморфизм. А полиморфизм — это всего лишь определенное поведение переменной.
Ну и наконец подходим к главному. В реальной жизни мы и понятия не имеем, как создается и как работает почтовый ящик, мы просто находим уже готовый объект и опускаем туда письмо. Надо сказать, что этот подход довольно долго не удавалось сформулировать и как-то его осмыслить, и только в середине 70-х годов английский компьютерный ученый Майкл Джексон (кстати Java-разработчики обязательно знают библиотеку для JSON-процессинга Jackson – она названа в его честь) описал паттерн, который мы знаем как IoC.
Вот мы и сформулировали три основных принципа ООП:
1. Message Passing
2. Late Binding
3. IoC
А то, о чем все говорят, - это просто приемы проектирования приложений с использованием языков объектно-ориентированного программирования.
Надеюсь, что интервьюеры прочитают этот мой опус и не будут больше задавать этот вопрос.
Комментарии (45)
WaterSmith
17.01.2025 13:56Смешались в кучу люди-кони. Мне кажется вы спутали, принципы ООП с паттернами проектирования. Обмен сообщениями, позднее связывание и инверсия зависимовстей, это замечательные и полезные вещи, которые хороши там, где нужны. Но при всем уважении, они никак не являются основными принципами ООП.
К слову, вы пишете:
Но современное поколение, в основной своей массе, почему-то считает, что ООП - это что-то новое, и к тому же неудачное, и поэтому его надо срочно заменить чем-то типа Питона или на худой конец Скалы итп.
Не понятно, почему вы противопоставляете ООП и Питон со Скалой? Это вообще сравнение теплого с мягким.
EvgenyKho Автор
17.01.2025 13:56Это примеры из реальной жизни, а не моя выдумка. Есть даже статьи на уважаемых порталах типа Medium, где пишут, что от ООП надо отказываться и переходить на Питон и тп. И пишут вроде бы специалисты с аргументами.
Я ничего не спутал, я говорю о принципах, которые при определенном взгляде могут стать паттернами. Паттерн - это способ решения похожих задач, этим словом можно обозвать вообще все...
SemyonVyatskov
17.01.2025 13:56где пишут, что от ООП надо отказываться и переходить на Питон
Они в курсе, что ООП можно прекрасно и замечательно реализовывать на Питоне?
Паттерн - это способ решения похожих задач, этим словом можно обозвать вообще все
Паттерн переводится как "шаблон". Слово "шаблон" означает не все что угодно.
Proscrito
17.01.2025 13:56"Новым поколением" автор согрел мне душу. Я-то уже давно чувствую себя старым :)
netricks
17.01.2025 13:56Вот это правильная статья про ООП
Я ещё позволю себе добавить, что ООП есть воплощение общеинженерного принципа декомпозиции и убежать от него никуда не получится. Хотя бы по той причине, что мы, люди, думаем объектами
GospodinKolhoznik
17.01.2025 13:56Когда я изучал Паскаль, мне казалось, что люди думают по-шагам. Когда я изучал Джаву, казалось, что люди думают объектами. Когда SQL, казалось, что удобнее всего думать, отдавая приказы другим. Когда ознакомился с Прологом, казалось, что люди думают фактами, а когда с Хаскелем, что люди думают функциональными зависимостями. А на самом деле никто не знает как думают люди, скорее всего они думают по большей части чувствами и эмоциями и немножко всеми вышеперечисленными способами.
Indemsys
17.01.2025 13:56По-моему, основной принцип ООП — это уменьшение сложности коллективного программирования любым путём, оставаясь в рамках текстовой нотации. Там, где сложность программирования ещё подвластна одному человеку, ООП по-прежнему успешно игнорируют.
Например, в малых встраиваемых системах. Вот буквально вчера увидел анонс от STMicroelectronics (ST) о том, что они перевели свою библиотеку по управлению моторами с C++ на C, и это значительно упростило её (с их слов).
netricks
17.01.2025 13:56Таки переход от с++ к си не означает отказа от ооп. Как известно, эталонное применение ооп, vfs ядра линукс - это вполне себе бодрый си
JBFW
17.01.2025 13:56Всякая вещь, будучи применена на своем месте, неминуемо приносит пользу (с) К.Прутков, 19 век
К сожалению люди часто любят приводить всё к одному знаменателю, запихивая ООП (то, которое с классами-наследованием-полиморфизмом) туда где оно нафиг не нужно.
netricks
17.01.2025 13:56Давайте зацепимся за эту мысль.
По сути у нас есть две разных сущности с одним названием.
Есть ООП как "Средства поддержки ООП" - это вот про классы, инкапсуляцию, композицию , полиморфизм и прочее.
А есть ООП как парадигма, как способ мышления и филосовский инженерный принцип
И это конечно же не одно и тоже. Тем не менее, по устоявшейся традиции и то и другое называется ООП
Indemsys
17.01.2025 13:56Однако ООП плохо гармонирует с требованиями реального времени во встраиваемых системах.
Сообщения между объектами — настоящее зло в системах реального времени. Для сообщений необходимо создавать очереди. Наполняемость очередей и их задержки нужно как-то оценивать, затем тестировать. И всё равно остаётся страх, что очереди переполнятся или приведут к недопустимым задержкам. Проще создавать жёсткие автоматы состояний с иерархией, без использования структуры программы в виде объектов.
Теперь автоматы часто создаются в графической нотации. А графическая нотация позволяет реализовать гораздо более сложную логику, чем текстовая. То, что раньше решалось с помощью текстового ООП, теперь может быть реализовано автоматами в графической нотации.
Симуляция, которая была одной из причин появления ООП, также перешла в графические среды. Всё меньшему числу людей необходимо знать о парадигме ООП.
dph
17.01.2025 13:56Вообще для отправки сообщений не нужны никакие очереди, сообщения могут отправляться (и обрабатываться) и мгновенно (как в http или в том же Smalltalk).
ООП никак не противоречит системам реального времени, более того, активно в них используется.
netricks
17.01.2025 13:56Тут у вас довольно много всего написано и тут есть что сказать.
Действительно, софт реального времени требует оптимизаций и специфического консенсуса между возможностями железа и математической стройностью. Во время оптимизации кода в бой бросаются специальные частные средства заточенные под вполне конкретный случай. Оптимизация всегда предполагает отход от парадигмы, какой бы она не была. Собственно поэтому и существует правило согласно которому оптимизация выполняется в последнюю очередь. Да, действительно, во многих приложениях декомпозиция, лежащая в основе ООП, вступает в конфликт с принципами работы кеша современных процессоров. Это сложно не заметить. Практика показывает, что оптимизации по быстродействию требуются, но требуются в довольно ограниченной области программы, в то же время хорошо декомпозированный код довольно легко транспонируется в оптимизированную форму, поэтому проблема эта разрешима
Что касается сообщений, я вообще говоря, считаю, что Алан Кей ошибался. Большая идея -это как раз таки объекты, а как они между собой связаны - дело десятое. Были попытки делать языки с трушным обменом сообщениями. Было грандиозное противостояние микроядерной и монолитной архитектур ОС, ярко выразившееся в мемной переписке Торвальдса и Таненбаума. Практика показала, что с настоящими сообщениями и без них получается один фиг, но без сообщений проще. К сообщениям между объектами следует относиться как к матмодели, хорошо приближающей то, что происходит в абстрактном объектном пространстве при вызове метода, но не более
Что касается графической нотации, на этот счёт существует консенсус. Графические языки это хорошо и правильно. Многие алгоритмы в них выглядят очень приятно. Кроме того существует возможность визуализации промежуточных вычислений. Это архиприятно, когда речь идёт, к примеру, о шейдерах. Шейдеры вообще отлично ложаться под графическое программирование. Тем не менее, существует потолок сложности, после которого граф становится неподдерживаемым. Читать и отлаживать программы написанные на графике сложно, поэтому не стоит ожидать, что человечество когда-то перейдёт на графику полностью. Ну и уж точно потоковая обработка графами никак не пересекается с теми сферами в которых доминирует ООП. Графы конкурируют, а на самом деле дополняют реактивную парадигму. И кстати, при манипуляциях над конвеером в рамках какого нибудь gstreamer становится очевидно, что обращаться с частями конвеера надо как с объектами. Никуда от этого не деться
А что до симуляции объектов реального мира, это пусть люди которые это придумали закопают это там, откуда они это взяли. Объектом в программировании могут быть функторы, алгоритмы, транзакции, даже ничто может быть объектом. Вот когда автор тезиса про объекты реального мира придъявит мне ничто как объект реального мира, вот тогда поговорим на эту тему
Indemsys
17.01.2025 13:56Графика как и ООП в смысле нотации нужны для одной и той же задачи - упростить программирование на верхнем уровне.
Самый низкий уровень по прежнему пишут на ассемблере, повыше на C и уже на верху C++ и скриптовые движки.
Появление ИИ заморозит эту схему, надобности в новых языках для упрощения ассемблера или С уже нет.
Потом графическая нотация все время совершенствуется.
Я лично считаю неудобными такие движки как Node-RED, Unreal Engine Blueprint, Labview, но считаю очень удобным движок Stateflow в MATLAB. С графами Stateflow роднят только стрелочки, а больше ничего общего.ООП как парадигма - это просто калька со здравого смысла.
Вот пункты этой парадигмы: фокус на объектах, модульность, повторное использование, удобство моделирования.
Любой адекватный программист будет делать программу модульной, будет делать шаблоны или заготовки, будет копировать взаимодейcтвия окружающего мира. Что тут такого уникального в этой парадигме? Какие могут быть альтернативы?
Нет, ООП - это прежде всего нотация, остальное от лукавого.
Или давайте трансформеров в ИИ обзывать ООП.
netricks
17.01.2025 13:56Когда-то революционной была идея процедуры. Вместе с ней появилось процедурное программирование. Но сегодня никто не считает процедурное программировпние чем-то интересным, потому что здравый смысл велит писать код процедурно. Потом пришёл дийкстр и потрясая теоремой Бёма-Якопини изрёк, что код надо писать структурно. Так родилась идея структурного программирования, но сегодня никто не скажет, что струетурное программирование это интересно, потому что все пишут код структурно.
Да, писать код объектно буквально означает "писать код в соответствии со здравым смыслом". Сегодня даже те, кто воюет против ООП пишут код объектно просто потому что они воспитывались в среде, где все пишут объектно и впитали эту идеологию "с молоком матери"
GospodinKolhoznik
17.01.2025 13:56Писать код объектно, значит объединить процедуры с данными так, чтобы работа процедуры неявно зависла от состояния данных. Насколько эта идея соответствует или противоречит здравому смыслу вопрос открытый. Конечно, так писать код немножко проще - не надо заботится о том, чтобы передавать в каждую процедуру весь необходимый набор входных аргументов, а все нужные ей данные будут переданы неявно. То же и с выходными данными.
Писать такое немножко проще. А тестировать? Гораздо тяжелее. Ну если у вас есть куча тестировщиков, которые каждый написанный вами метод протестируют вдоль и поперек, при всех возможных комбинациях значений состояния данных в объекте, тогда несомненно только так и надо делать. Если же с неба дождь из тестировщиков не льётся, то уже не факт, что методы были хорошей идеей.
Писать код с неявной передачей аргументов и неявным возвращением значений удобно, но какой ценой даётся это удобство? Всё равно по факту все эти неявные параметры приходится учитывать в голове, постоянно о них думать - а какое там состояние у объекта, а точно ли метод отработает так, как я предполагаю, или возможно состояние, при котором логика работы нарушится? Это требует постоянной концентрации внимания и очень сильно изматывает. А за длительное время приводит к выгоранию. Конечно, всё можно решить 100% покрытием юнит тестами, но времени на исчерпывающее написание тестов бизнес не даёт - подгоняет. Да и писать юнит тесты, которые будут учитывать все возможные состояния данных объекта это задача высокой комбинаторной сложности. А потому все приходится делать за счёт повышенной собранности и максимальной концентрации внимания. По себе замечал, что из всех парадигм программирования, ООП подход изматывает нервную систему сильнее всего.
tbl
17.01.2025 13:56При переходе на C придется забыть про хэш-таблицы: "Библиотеки от проекта GNOME, которые написаны в парадигме gobject - это г... лютое, там на каждый чих по 10 аллокаций памяти, и линейный перебор по куче связанных списков.
А все потому, что в С еще не изобрели хеш-таблицу".
netricks
17.01.2025 13:56Помойму это очень странное заявление... во первых я не понимаю, какое отношение это имеет к теме, а во вторых, никаких проблем с использованием хештаблиц в си нет
Lewigh
17.01.2025 13:56Мое мнение что главная проблема современного ООП что никто толком даже не понимает что это вообще такое. Все есть объект? Если взять столпы ООП в виде C++ и Java, там все есть объект? Нет. Инкапсуляция, наследование, полиморфизм? Прекрасно существуют и в не ООП языках и не делают их ООП языками.
По моему личному мнению, современное ООП это не целостная самодостаточная концепция с четкой теоретической базой, целями, задачами и путями их решения. Современное ООП - это просто одно из направлений развития старого доброго структурного программирования к которому добавили идею еще одного уровня модульности (на уровне структуры) и прикрутили несколько свистоперделок в виде наследования типов и динамической диспетчеризации а также назвали это модным по тем годам словом.
Именно по этому, за несколько десятилетий так и не научились как на нем правильно писать а эволюция написания ООП программы пришла к простому процедурному стилю, где нужно иметь тупые объекты только с данными и сервисы без состояния.
gelioson
17.01.2025 13:56Мне кажется, тут суть в другом.
Изначальная идея ООП - это объединить данные и методы их обработки в некую единую сущность - объект. Для своего времени идея была прорывная: позволяла скрывать реализацию и выставлять наружу простой интерфейс, выносить общий код в родителя, и все такое, чем знаменито ООП. И не сказать, что оно плохо работает, тот же гуй на ООП вполне себе ложится.
Потом научились делать многоядерные процессоры и ВНЕЗАПНО оказалось, что объекты с мутабельным стейтом очень плохо ложатся на многопоточность. Ну и, почесав репу, умные люди решили данные и методы разделить, но на качественно ином уровне: пусть у нас будут глупые данные (в идеале немутабельные) отдельно и функции для их обработки (в идеале чистые) отдельно. Получилось вполне неплохо: отлично параллелится и векторизуется, очень удобно писать автотесты. Модный реактивный поход тоже залетел.
В итоге каждый подход хорош в своей области. Многие языки поддерживают оба похода, и это хорошо: UI с окошками и формочками удобнее писать на ООП, а обрабатывать данные с бэка, фильтровать, форматировать и байндить на UI удобнее функциональщиной. А когда пытаются натянуть одно на другое - начинаются непонимания, конфликты, боль и страдания.Это как ОТО и квантовая механика: каждая неплохо работает в своих границах применимости, а если попытаться натянуть одно на другое - фигня получается. Ученые пытаются разработать Единую Теорию Всего - пока выходит не очень, но кто знает. Глядишь, и в программировании изобретут подход, сочетающий преимущества ООП и функциональщины.
AlexTest
17.01.2025 13:56Цитаты Алана Кея - отца ООП, которые "в тему" статьи:
Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++.
Я жалею, что придумал термин «объекты» много лет назад, потому что он заставляет людей концентрироваться на мелких идеях. По-настоящему большая идея — это сообщения.
Ключ к тому, чтобы делать большие и расширяющиеся системы, заключается в том, чтобы придумывать, как модули будут общаться друг с другом, а не заботиться об их внутренних свойствах и поведении.
EvgenyKho Автор
17.01.2025 13:56Немного странные комменты. Я пытался рассуждать об идеологии, но комментаторы почему-то сваливаются в реализации. Если говорить о конкретных языках, то большинство из них обладает одним и тем же недостатком - статические сигнатуры методов для обработки сообщений. А идея в том и состоит, чтобы сообщения были максимально произвольные. Некоторые утверждают, что бывают кейсы, в которых структура сообщения вообще неизвестна.
GospodinKolhoznik
17.01.2025 13:56На протяжении последних 50 лет развитие программирования идёт в том направлении, чтобы каждый кусочек программного кода давал разработчику как можно меньше свободы - только лишь чтобы выполнить в этом куске кода минимальное необходимое действие и ничего больше. Как показывает практика, при таком подходе возникает меньше ошибок, и меньше уязвимостей, и проводить рефакторинг такой системы гораздо проще. А что хорошего в том, чтобы сообщения были абсолютно произвольные? Например, чтобы была возможность передавать в сообщениях произвольный исполняемый код или sql инъекции?
EvgenyKho Автор
17.01.2025 13:56программирование развивается в разных направлениях... код - это не сообщение, код сам обрабатывает сообщения. Речь идет о блэкбоксах. ЧТоб было понятно, давайте пофантазируем. Вот у нас есть пос-терминал, он может обработать: visa, mastercard, jcb и даже Американ Экспресс... уже какая-то степень произвольности достигнута, причем, когда мы платим, мы вообще не задумываемся, сколько там всего происходит... А вот есть еще средство платежа, как наличные или еще того круче - криптовалюта! - и уже этому пос-терминальчику слабо, не умеет он такие сообщения обрабатывать. Но ведь нам нужно сделать то же самое действие - заплатить. Т.е. повернуться надо лицом к человеку! а не к компьютеру. Вы все заботитесь о том, как систему создать, а нужно беспокоиться о том, какие сообщения приходят в систему. Но рассуждать о таких вещах в эпоху роботов и ИИ более, чем странно.. Я просто хочу, чтобы мне про ООП вопросы не задавали.)))
dph
17.01.2025 13:56Нет никакой произвольности на POS-терминале. Там есть очень жесткий протокол, все возможные обработки которого (для VISA/MC/etc) жестко описаны. Нет возможности в POSе использовать вместо банковской карты - какую-то другую (например, телефонную).
В реальном мире (и в проектировании) как раз сообщения, которые может обработать объект - всегда жестко специфицированы. И ООП - как раз про это.EvgenyKho Автор
17.01.2025 13:56Даже странно об этом писать... pos-terminal - это всего лишь считыватель информации, а протокол общения с системами оплаты там тот, который вы в него заложите, и жестким он будет именно настолько, насколько жестким вы его сделаете... даже странно это объяснять.. Считанная информация может проходить через несколько систем с разными протоколами, а сама оплата произойдет на 5-й ступени неизвестно где.... Вы не хотите думать... Блэкбоксом здесь является ваша программа, которая обрабатывает считанную терминалом информацию. А терминал можно сделать, что он будет считывать криптокошельки или принимать доп. ввод инфы ..... Все ваши заявы только подверждают отсутствие понимания ООП и принципа Message Passing. А уже не говорю про то, что вы там про IoC - там не о чем говорить, настолько там все очевидно.
dph
17.01.2025 13:56Pos терминал имеет дело с конкретным форматом записи на карте (чип), поддерживает сложный протокол для работы с этим чипом (ISO 8583, загрузка ключей, работа с сеансами и так далее). И без этой жесткой логики, описывающей сообщения как от эквайера к POS, так и взаимодействие POS и карты - никакие платежи по карте невозможны. При этом весь обмен от банковской карты и до банка-эмитента жестко описаны документацией в несколько тысяч страниц.
И, в рамках ООП, карта, POS, софт эквайера, софт эмитента, софт ПС - как раз объекты, обменивающиеся сообщениями. При этом форматы (типы) сообщений жестко описаны, а вот сама логика - да, может быть очень гибкой. Собственно, в этом и есть смысл ООП
2. Кажется, вы не понимаете не только принципы работы POSов, но и ООП и процессы передачи сообщений. Благо уж по ООП много литературы и там описано и что такое сообщение и что такое объект.
Собственно, о том, что вы не очень разбираетесь в ООП - уже написало довольно много человек.
EvgenyKho Автор
17.01.2025 13:56насчет много человек - не аргумет, мнение толпы чаще всего ошибчно, и апеллировать к толпе - это путь плохого человека.. И при чем здесь формат записи? Надо исходить из того, что у вас есть какое-то средство оплаты и вам нужен объект, которому надо передать сообщение об оплате - все. А вы мне про какие-то реализации... может быть ISO 8583, а может что-то другое... а может это вообще никому не надо... В таком случае программирование сводится к тому, что вы должны думать, что делать с этим сообщением об оплате, а не о том какой протокол использовать для обмена фин. информацией. Если вы будете ориентироваться на сообщения, вы будете как-то иначе строить приложения для процессинга. А вы с самого начала загоняете сообщения в жесткие рамки, диктуете, какой должен быть формат, и как можно более жесткий формат, по вашим же понятиям.
Но самое главное, что дверь уже давно открыли, и проблемы эти давно решены.
пс тут кто-то из толпы пишет, может даже вы, что отцы основатели ООП вообще лохи позорные, тоже не понимают, что такое ООП, и вот только обитатели хабра....
EvgenyKho Автор
17.01.2025 13:56я помню по молодости, когда общался с бизнесом, тоже объяснял им, что я не смогу ничего обработать, если мы четко не договоримся о формате сообщения, что все должно быть жестко формализовано итп. А они не понимали, почему нельзя сделать гибко. И в конечном итоге выяснялось, что такое жесткое приложение мало кого заинтересует. А потом и мне становилось ясно, что надо искать другие пути.
dph
17.01.2025 13:56Хм, похоже, вы просто не понимаете, что такое POS. Он не отправляет никакой информации об оплате. Процесс оплаты вообще происходит довольно далеко от POS. Лучше не использовать примеры из областей, в которых не разбираетесь.
Я не очень понимаю, откуда взялось противопоставление "сообщений" и "формата". Сообщения - всегда в каком-то конкретном протоколе, в конкретном формате и содержат конкретную семантику. И ООП, в том числе, и об этом. И как раз про это и пишут основатели ООП.
dph
17.01.2025 13:56Очень странная идея. Идея как раз в том, что для объекта известно, какие именно сообщения он может обрабатывать, но не известно, как именно. Если структура сообщения неизвестна получателю, то как он может его обработать?
Lewigh
17.01.2025 13:56Я пытался рассуждать об идеологии, но комментаторы почему-то сваливаются в реализации.
Потому что программы пишуться на реализации конкретных решений а не на идеологии. Большого смысла рассуждать как было бы хорошо если бы... нет.
Если говорить о конкретных языках, то большинство из них обладает одним и тем же недостатком - статические сигнатуры методов для обработки сообщений.
Наверное потому что методы это не обработчики сообщений а методы.
А идея в том и состоит, чтобы сообщения были максимально произвольные. Некоторые утверждают, что бывают кейсы, в которых структура сообщения вообще неизвестна.
А что в этом такого сакрального и зачем вам это именно в ЯП? Хотите построить архитектуру где обработчики будут получать сообщения и произвольно обрабатывать их, напишите. Вот есть акторные модели есть архитектурное модели такого построения.
Вот у меня сейчас на проекте именно такая - микросервис получает сообщение через кафку и обрабатывает только те которые знает, остальные игнорирует. Что это такого даст если это внедрить на уровень ЯП?
SadOcean
17.01.2025 13:56Я думаю что ваша интерпретация так же не верна, как и классическое "инкапсуляция, полиморфизм, абстракция".
Концептуальная идея крайне проста - сложную систему нужно разбить на автономные части с данными(объекты), которые взаимодействуют друг с другом через сообщения.
Вот и все.
Из этого следуют многие полезные свойства - объект может контролировать целострость своих данных, код и данные по обработке локально сконцентрированы, их удобнее читать. Код легче переносить, потому что объекты связаны только через сообщения. И т.д.
В целый ряд парадигм этому неплохо соответствует. Языки, которые были написаны на основе этой идеи, реализовали их через разные инструменты - классы и объекты как продвинутые методы структур, слитых с методами, методы как типизированные сообщения, интерфейсы и полиморфизм для абстракции сообщений (то самое, что нужно знать про сообщение, а не кто и почему его обрабатывает), наследование как вспомогательный механизм организации. Многие языки буквально поддерживают сообщения.
Развитие этих языков привело к тому, что сейчас все больше сосредотачиваются на инструментах, чем на концепте.
Это не лишено смысла, потому что на этом велосипеде в любом случае нужно научиться ездить.
Но суть немножко теряется.
В этом смысле то, как мы используем объекты в классических языках - это не объекты, о которых говорил Кей, это их запчасти.
В общем кажется, что это и приводит к всему трешу вокруг этого вопроса.
EvgenyKho Автор
17.01.2025 13:56Концептуальная идея крайне проста - сложную систему нужно разбить на автономные части с данными(объекты), которые взаимодействуют друг с другом через сообщения.Вот и все.
Это верно, но вы почти что скопипастили фразу из моего текста... и я не против.
gun_dose
17.01.2025 13:56письма любого типа: закзаные, открытки, микро бандероли …. типа того..
Вот это самый обычный полиморфизм. Все перечисленные вами типы отправлений имплементируют один и тот же интерфейс, в котором подразумевается наличие как минимум адреса получателя и марки. Конверт без адреса или конверт без марки не будет обработан. Равно как не будет обработан любой другой предмет, попавший в ящик, но не имплементирующий интерфейс почтовой корреспонденции. И как видите, типизация тут абсолютно ярко выражена.
JBFW
"Это другие обьекты" )
А то, о чем вы говорите - вас сейчас тапками закидают, потому что у вас "тип посылки заранее не определен", а сейчас в моде "типизация": ваша посылка в почтовый ящик не пройдет, потому что этот ящик строго под определенную форму посылки.
EvgenyKho Автор
Ну, ограничения всегда есть, понятно, что автомобиль посылают какой-то другой почтой...
dph
Хм, вообще в ООП как раз тип сообщения - известен. ООП (еще со времен smalltalk) про объединение данных и методов с ними работы. Методы работы - да, можно описывать как отправку сообщений. Важно, что у конкретного объекта известно, какие сообщения он может принимать и при отправке - не важно и даже не известно, как именно они будут обрабатываться.
IoC - это поздний паттерн, ООП может быть и без IoC.