(Источник)
Хочу внести свои «5 копеек» в неутихающий спор противников и сторонников ООП. Из недавних публикаций на эту тему можно отметить ярко негативный заголовок «Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ», более миролюбивый «Хватит спорить про функциональное программирование и ООП» и умеренно позитивный «Объектно ориентированное програмирование в графических языках».
Но на идею этой заметки меня натолкнул комментарий к другой статье:
Отличный пример для того, что ООП — это просто ужас. Система трейтов отлично реализует ваш случай, и совершенно не требует отвечать на Экзистенциальный Вопрос Объектного Программирования — «Что Есть Объект?». [...] Забудьте про ООП, это была удачная для GUI метафора, которую попытались возвести в статус религии.
На мой взгляд, это очень показательный типичный комментарий, где критикуется не сам ОО подход (даже отдается должное ООП в GUI), но мифы, возникшие вокруг ООП. Таким образом, на мой взгляд, правы все: и сторонники, когда указывают на удобства ООП, например, при программировании GUI, и противники, когда негодуют на возведение ООП в статус серебряной пули, абсолютного оружия.
Сразу стоит отметить, что в каждом ОО ЯП свой ОО подход, иногда сильно, иногда не очень сильно отличающийся от других ОО подходов. Буду исходить из умеренного простого подхода ОО Паскаля, заложенного еще в Turbo Pascal 5.5 и окончательно оформившегося к Delphi 7 (можно отметить и близкие по концепции ЯП других производителей, например, Think Pascal для MacOS). В этом ОО подходе есть основополагающие принципы: инкапсуляция, наследование (простое), полиморфизм; и существенные ограничения: например, нет по сути очень непростого множественного наследования.
Как уже написал в комментарии к упомянутой выше статье — переход от классического Паскаля к ОО Паскалю выглядел, на мой взляд, очень наглядным и оправданным:
Простейшая инкапсуляция уже есть в записях (record). Далее понятие о наследовании приходит в таких простых примерах:
type TCoord = record // координаты точки x, y : integer end; TRect = record // прямоугольник leftTop, RBot : TCoord; end;
Остается заменить слово «record» на слово «class» (с указанием имени предка в скобках), разрешить записывать заголовки методов внутри таких «записей» и оговорить несложные правила полиморфизма.
Приведенный пример — реализация графических примитивов, это уже более широкая задача, чем задачи GUI. Здесь иерархия объектов выглядит очевидной и не возникает отмеченного выше «Экзистенциального Вопроса „Что Есть Объект?“». — Понятно, что точка — объект и прямоугольник — другой объект. Но в общем случае четко выделить объекты и расположить их в единственно правильную иерархию далеко не всегда возможно. Здесь противники ООП правы, но дело в том, что это не нужно! ОО подход часто называют модельным подходом (одним из). Основной принцип модельного подхода — моделирование не всех свойств прототипа, а только некоторых, значимых свойств для целей данной модели. Хрестоматийный пример — испытание модели самолета в аэродинамической трубе. Очевидно, что для таких испытаний не нужно делать у модели двигатели, иллюминаторы, шасси, убранные при полете в корпус и кресла в салоне, как и сам салон — достаточно выстругать эту модель из цельного куска дерева, воспроизведя только предполагаемые обводы корпуса. Такие испытания проводят не только для реальных моделей в реальной трубе, но и для виртуальных моделей в виртуальной трубе. Если реализовать виртуальное испытание с применением ООП, то принципы будут аналогичные реальным испытаниям — ненужные свойства и обекты в программу не попадут. Но если мы захотим повторно использовать код этой модели для моделирования дизайна самолета, то можем столкнуться с иерархическими проблемами при добавлении новых объектов. Является ли это недостатком именно ООП? — На мой взгляд нет: всякое моделирование сопряжено с жесткими ограничениями. Более того, для моделирования существует ряд других сложных принципиальных проблем. Подробнее см.:
Блехман И.И., Мышкис А.Д., Пановко Я.Г. Механика и прикладная математика. Логика и особенности приложений математики.
Мышкис А. Д., Элементы теории математических моделей. Изд. 3-е, исправленное. М.: КомКнига, 2007
В приведенных книгах упомянуто много источников на тему моделирования, в том числе цитируется следующий пример. Если поставить 3 табуретки друг на друга, то эта конструкция будет вполне устойчивой, чтобы водрузить на нее бумажный кубик для школьного урока рисования. Но эта же конструкция явно неустойчива, чтобы с ее помощью поменять сгоревшую лампочку. Никакая математика сделать такие выводы не сможет. Таким образом, существует не чисто математическая проблема интерпретации результатов моделирования. Эта проблема будет возникать в любой реализации модели: как с применением, так и без применения ООП. Но люди склонны к когнитивному искажению, и зачастую обвиняют инструмент-зеркало в отображении неприятной им информации ;)
В конце прошлого века всемирно известные люди Билл Гейтс, Филипп Кан, Бьёрн Страуструп, Никлаус Вирт и др., не желая того, заложили бомбу под ООП, слишком восторженно его пропагандируя. Почти все им поверили, и только сейчас наступило отрезвление. Но этот процесс отрезвления опасен другой крайностью — попытками полного отказа от зарекомендовавших себя во многих областях технологий. Только попыткой — вряд ли это возможно, хотя бы потому, что:
прежде всего забыть ООП [...] не реально, т.к. очень многие IDE имеют графические инструменты для создания GUI, и эти инструменты генерируют ОО код.
На мой взгляд, как и в случае любой модели, от модели с применением ООП не стоит ждать, что она чудесным образом раскроет все тайны мироздания. Каждая модель адекватна только в своих узких рамках: «что заложено — то и получим». При этом, согласно требованию естественно-научного подхода, каждый результат, полученный на модели, должен быть перепроверен экспериментально. Но при таких природных ограничениях существуют не всеми осознанные бонусы: к моделированию зачастую возможен примитивно-формальный подход. Так, в случае ООП не нужно пытаться вникнуть глубже возможного при определении объектов и их иерархии. (Аналогично, например, в химии: современные химики знают, что атом не шарик, а химическая связь не стержень фиксированной длины, но это не мешает им использовать шаростержневые модели и структурные формулы.) — Иерархия нужна, чтобы навести порядок в коде модели, но она никогда не будет в точности отвечать гораздо более сложному, чем всякая модель, прототипу.
TonyLorencio
Стоит отметить, что в большинстве ЯП объектно-ориентированный подход упрощен настолько, что от изначальной концепции, когда объектам посылаются сообщения (которые также являются объектами), а первые на них реагируют, остался всего лишь вызов метода, что уже принципиально мало отличается от традиционного процедурного программирования.
vav180480
А зачем всенепременно следовать концепциям?
adictive_max
Вы так говорите, как будто это что-то плохое. Программирование — это не предмет для философских дискуссий, а инструмент для решения задач. Что плохого в том, чтобы из каждого ящика с инструментами взять только самые удобные, не ограничивая себя выбором только какого-то одного самого лучшего ящика?
TonyLorencio
Нет, конечно, это не плохо и не хорошо. Вызов метода просто оказался удобнее, и потому этим мы пользуемся сейчас.
Source
Не удобнее, а проще в реализации с приемлемой скоростью. Впрочем, с тех пор уже столько лет утекло, что теперь единственным аргументом за вызов метода остался "привычнее".
third112 Автор
Кроме скорости: чем лучше создавать объект-сообщение конструктором, а потом уничтожать его деструктором? Разве это не потребует больше строчек исходного кода?
VolCh
Обычно ни конструктор не создаёт объект, ни деструктор его не уничтожает. Первый его инициализирует, втрой — очищает.
third112 Автор
На старте программе м.б. неизвестно сколько каких объектов будет нужно. Значит придется динамически создавать (и уничтожать) по мере необходимости в ходе выполнения.
VolCh
Именно "при создании", а не "для создания". Конструктор объект не создаёт. Из мэйнстрим языков разве что в JS конструктор может опционально создавать новый объект, а не инициализировать созданный рантаймом
third112 Автор
Не понял. Вот конкретный пример:
Здесь при создании основной формы создается 1 орграф, 1 неориентированный и 1 неориентированный большой. Позже могу заказать программе с консоли сделать еще 100 орграфов, а предыдущие удалить для экономии памяти. А инициализация dg, ug и bg в другом месте.
black_semargl
Тут конструктор создаёт ряд других (внутренних) объектов, но не тот объект конструктором которого он является.
third112 Автор
Каких других объектов?
black_semargl
Ну как я понимаю — кем-то создаётся объект типа TMainForm, вызывает свой конструктор, из него FormCreate, в котором создаются три вложенных объекта T*Graph
third112 Автор
Вызов TDirectedGraph.create (и т.д.) в обработчике события создания окна — обработчик TMainForm.FormCreate, но create, создающий экземпляр (обект) типа TDirectedGraph, определено в TDirectedGraph.
Source
Я думаю, VolCh справедливо имеет в виду, что основной этап создания объекта — это аллокация памяти для него. В большинстве ЯП этот этап скрыт и не прописывается в конструкторе.
third112 Автор
Да. Он скрыт, но память под объект должна выделяться динамически при вызове конструктора.
VolCh
Не при вызове конструктора, а при вызове оператора new или аналога. Создание объекта, грубо:
third112 Автор
Ну так выделение памяти и т.д и происходит при вызове конструктора (речь про вызов в исходном коде!). Пока нет вызова прога не знает, что нужен новый объект. Можно в отладчике ассемблерный код посмотреть.
dg := TDirectedGraph.create;
Открываете окно CPU и далее шагаете по коду с говорящими именами:
@getMem
call @classCreate
TObject.NewInstance
call TObject.InstanceSize
call @GetMem
call dword ptr [MemoryManager]
SysGetMem
call TObject.Create
и т.д.
khim
thisне был константным в конструкторе и ему можно было присваивать… но это уже история сегодня, конечно…Source
Сообщение — это вообще данные, причём тут конструкторы/деструкторы?
А лучше тем, что объекты, общающиеся передачей сообщений, не связаны жёстко друг с другом, соответственно на порядки проще становится писать надёжные и масштабируемые системы.
third112 Автор
Возьмем класс TRect из моего примера. Пусть в этом классе будет метод draw, отрисовывающий прямоугольник. Попробуем смоделировать передачу сообщения drawMsg («рисовать») с помощью данных:
Не вижу преимуществ такого кода: ни доп. надежности, ни масштабируемости.
Source
Было сказано, но не мной )
Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.
Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги и животные? А авторов, которые такие примеры в книгах используют, разместят на большую доску позора. Всё это настолько безумно далеко от практических целей ООП, что дальше некуда. И на этих вырожденных и абсолютно бесполезных примерах любые преимущества (даже ООП vs ПП) высосаны из пальца.
Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
Очевидно прокинуть эвент для обработки ряду объектов.
Пока преимуществ не видно?
Но давайте представим, что этим объектам не обязательно находится на одном сервере. В случае, с вызовом метода — это невозможно, все объекты должны быть в памяти процесса, чтобы можно было вызвать их методы. Для передачи сообщений такого ограничения нет, и все 4 объекта из примера могут находиться на разных серверах (масштабируемость из коробки).
Теперь представьте, что с объектом logger что-то случилось, например упал с ошибкой. Достаточное ли это условие, чтобы похерить всю обработку эвента? В большинстве систем обработка эвента гораздо важнее его логирования. Но чтобы обеспечить пропуск опциональных шагов, вам придётся каждый из их завернуть в try (мда, ппц как удобно). В случае с сообщениями, вы можете легко сделать sendMsgAsync и не ждать возврата результата, когда он не важен. Бонусом, вы получаете возможность все опциональные действия выполнять в отдельном потоке. А что будет с нашим упавшим из-за какого-то хитрого эвента логгером? А он зареспаунится с исходного состояния, без необходимости восстанавливать что-то после сбоя, без необходимости перемешивать обработку ошибок с бизнес-логикой и т.д.
Я в курсе сколько костылей напридумано, чтобы получить похожие результаты в ООП с вызовом методов. Однако для этого достаточно перейти на передачу сообщений между объектами.
third112 Автор
См.:
Далее:
Рисование графических примитивов очень важная практическая цель любого универсального программирования, нпр., для GUI.
tive will be prosecuted; persons attempting to find a
moral in it will be banished; persons attempting to
find a plot in it will be shot.
BY ORDER OF THE AUTHOR,
Per G.G., Chief of Ordnance.
Source
Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:
Как видите, тут нет никакого требования чтобы сообщения были объектами. Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.
Да что вы говорите… и что же в GUI есть кроме прямоугольников, которые по-хорошему рендерит ОС (мы же хотим нативный look-n-feel, не так ли), используя процедурный код?
Да и если вы не разработчик GUI framework, то это вообще вас не касается. Вы ООП для бизнес-логики используете, а не для отрисовки кнопочек.
Мы тут ООП обсуждаем, а не Виндов ХР. Вы предлагаете обмен сообщениями между объектами вести не средствами ЯП, а средствами ОС? Ну и я же написал, что я в курсе наличия извращений разных сортов, в том числе типа COM и CORBA (неужели это кто-то до сих пор использует?). Они все нафиг не нужны, когда у вас есть ООП на базе классического определения.
Если у вас есть ООП — у вас уже есть клиент-серверное программирование. Если его нет, то у вас нет и ООП. Вот цитата с OOPSLA 1997:
"So this is an early insight that objects basically are like servers. This notion of polymorphism, which used to be called generic procedures is a way of thinking about classes of these servers. Everybody knows about that."
Только задумайтесь, 22 года назад все знали, что объекты должны играть роль минисерверов. А сейчас приходится это разжёвывать.
Много чего есть… Можете ознакомиться: https://en.wikipedia.org/wiki/Programming_paradigm
Но если хотите предметно поговорить про ООП, то сначала ознакомьтесь с этой частью:
Actor-based OOP (ближе всего к классическому ООП)
third112 Автор
По сути:
В принципе я не против содержательной философии, но тут она явно избыточна и только наводит тумана. Нпр., я бы не стал называть переменную Х вещественного типа объектом. И я бы не назвал константу 3.14 обектом. И я бы не сказал, что операция присваивания переменной Х этого значения есть операция инициализации объекта:
И никакой инкапсуляции. И где тут сообщение? Но, наверное, есть подходы, где «Everything is an object.»
С этим не спорю.
ИМХО термин «бизнес-логика» размытый, плохой, нелепый. ИМХО очевидно: бизнес это деньги. В явном виде деньги не во всяком коде, а если и есть, нпр., в коде игры, то галактические кредиты 3300 г. — не те это деньги, которые хочет кодер) Поэтому ИМХО лучше использовать синоним: логика предметной области (domain logic). Иногда отрисовка «кнопочек», т.е. элементов контроля GUI это логика предметной области: нпр., клетки периодической таблицы (не обязательно прямоугольные).
Столь резкое утверждение нуждается в строгом доказательстве. (Возможно ли математически строго доказать, что технология Х — извращение? — Термин «извращение» не мат. термин, поэтому думаю, что это не более чем субъективные оценочные суждения, как с Вашей, так и с моей стороны. Большого значения они не имеют.)
См.:
Далее:
Т.е. никакой из существующих ЯП такой механизм не использует? Попытаюсь расшифровать этот псевдокод:
Посылаю асинхронно сообщение event через eventLogger. Если функция sendMsg возвращает ложный статус — остановить программу. Кортежам «статус, событие» и «статус, отклик» присвоить «обогатитель» (?) события и хандлер события. И зачем нам такие кортежи? Полный туман:
1) sendMsgAsync посылает сообщение определенному объекту (объектам) или всем объектам в инете?
2) Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?
3) Должен быть единый список сообщений, понятный всем объектам?
4) Какой формат сообщения? (сколько в нем полей, символов, целых и нецелых чисел и т.д.)
5) Если сообщения в инете, то они должны шифроваться для безопасности?
Я не про всё, что есть. А про ОО подход, который представляется ИМХО более совершенным, чем обмен сообщениями.
Не упустил, но и при повторном прочтении не увидел там особо интересной информации по теме. Речь там о незнакомом мне ЯП «в ответ на вопрос о парадигме языка». М.б. кто знает этот язык — тому интересно. А у меня даже общего представления не сложилось. Есть много статей на подобные узко-специальные темы, почему я должен был не упустить и упомянуть именно эту?
Source
Тот, кто ввёл термин ООП (Алан Кэй), тот и был первым, очевидно же. Цитату можно найти в The Early History Of Smalltalk, но скорее всего она и раньше публиковалась в статьях на эту тему.
Давайте я вам расшифрую, "Everything is an object" означает только одно: никакой код, из написанного вами, не может выполняться вне объекта. Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.
Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете? В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев. Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. А не в том, что кружочки никогда не понадобятся. Может и понадобятся пару раз за 10 лет… Кто вас знает, может вам даже кролики, унаследованные от Animal, понадобятся для периодической таблицы. Вот только в ежедневной работе программисты другими вещами занимаются.
В контексте данной дискуссии этот термин используется лишь для сокращения "делать простые вещи сложным и нестабильным способом", в простонародье "через задницу", например: имея 2 руки, управлять трекпадом ногой.
Кстати, каким боком цитата про то, что 17 лет назад в .NET включили средства для работы с COM+, доказывает актуальность CORBA в наши дни?
Использует (напр. Erlang, Elixir, LFE и т.д.), но не буду же я вас через комментарии новому ЯП учить. Это к вашему изначальному непониманию чем сообщения удобнее методов отношения не имеет.
Разумеется конкретному, я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.
И что?
Нет.
Любой. Any Data.
Да, такая опция есть. Однако, даже если объекты на разных машинах, они не обязательно выставляются в инет, есть локальные сети в пределах одного ДЦ для этого.
Потому что она на тему ООП. И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk и c Erlang/Elixir. А до тех пор вы будете не в теме. То, что вам на текущем этапе знакомо это не ООП, это попытка добавить часть идей ООП в Pascal.
third112 Автор
Прежде всего:
Не говорите за всех. Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются. В то же время именно научные учреждения обеспечивают прогресс в программировании. Т.о. это с Вашей стороны «диверсия» приземлять всё до уровеня промышленной разработки :)Абсурд так говорить о задаче для образования.
Или к Вашему изначальному непониманию, чем методы удобнее сообщений ;)
А выше сказали:
И опять сказали:
Так имеет Smalltalk отношение к сути вопроса или не имеет? — Похоже, что Вы сами запутались :)
BTW:
Вот случай мифа о котором в статье:
Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП. А еще говорите о промышленной разработке!
У Вас
Где у меня eventLogger?
Более того Вы ж сказали, что возьмете не мой, а свой пример:
Опять запутались!
И «прокинуть эвент для обработки ряду объектов» это не
Снова запутались?!
Далее я спросил:
Вы ответили классически вопросом на вопрос:
Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет. Не буду комментировать такой абсурд.
Source
Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.
Есть абстрактная идея ООП, а есть её реализации. Поскольку вы хотите не только теорию, но и конкретику, то вам придётся ознакомиться и с реализациями ООП:
Smalltalk — классическая class-based реализация ООП
Erlang/OTP — actor-based реализация ООП
При этом то, что справедливо для конкретной реализации, не всегда справедливо для парадигмы как таковой.
Да в принципе никакое, пока вы сами по себе что-то там пишете, можете хоть своим личным ООП руководствоваться. Но раз взялись писать статью, то потрудитесь хоть немного разобраться в теме, прежде чем писать о ней. И нет, прочитать одну статью на википедии недостаточно.
OMFG, вы читать вообще умеете, я же русским языком написал, что взял синтаксис из вашего примера, чтобы вам понятнее было. Напоминаю:
sendMsg ({куда}, {сообщение});Каждая строка отправляет сообщение конкретному объекту, а все вместе они образуют ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)
О чём вы вообще говорите? Какие миллионы компов всей Земли? Хоть это и происходит, но это вообще не в тему обсуждения. Вы вообще понимаете, что такое горизонтальное масштабирование системы? Или кроме desktop-приложений на Delphi ничего не делали?
third112 Автор
Ваше упорство в попытках донести свою позицию могло бы вызвать определенное уважение, если бы не два обстоятельства: по-детски мелочные нападки (на которые тратите значительную часть своих комментов) и слепой фанатизм.
Пример нападок:
И это Вы заявили при явном отсутствии информации (когда другой на Вашем месте промолчал бы до получения большей информации). Будет Вам известно, что те самые кружочки могут обозначать вершины молекулярных графов или атомы. А изучение таких графов позволяет, нпр., проектировать вещества с заранее заданными свойствами, нпр., новые лекарства.
Что касается фанатизма, то здесь первым делом нужно отметить Вашу убежденность в превосходстве промышленной разработки над научной и в том, что сообщения удобнее методов. Вы даже не понимаете что тут доказывать — произносите слово «логер» и Вам кажется, что каждый должен склоняться перд ним в трепете. А между тем Вы даже задачу толком не сформулировали. Так и осталось непонятным зачем этот ряд:
М.б. и попытались что-то объяснить, но с объяснениями, как и с доказательствами у Вас явно не получается. Про свой вывод о Вашей трактовке ООП я уже сказал в предыдущем комменте.
0xd34df00d
Я, конечно, дико извиняюсь, но это следует из первого пункта тупо посредством формальной логики. Сообщение — это что-то, что можно пощупать внутри языка (как минимум, его можно создать, отправить или получить). Значит, это объект по п. 1.
Третий пункт я, впрочем, понять не могу, но это так, к слову.
black_semargl
С одной стороны да, но как тогда к нему применить второй пункт?
0xd34df00d
А в чём вопрос?
Можно отправить сообщение сообщению. Можно отправить сообщение сообщению сообщению. И так индуктивно, по крайней мере, до первого счётного ординала.
third112 Автор
Ok. Для обфускации очень подойдет :)
EvgeniiR
Ничего плохого, но ни слова про удобство в комментарии на который вы отвечаете не было, и далеко не факт что именно удобство стало причиной такого упрощения.
khim
Не удобства точно. Простота понимания и реализации исключительно.
Antervis
не думаю что дело в этом. Вряд ли Smalltalk, реализующий кошерный ООП и написанный в 80-х был сильно непонятным или сложно реализуемым. Проблема, полагаю, скорее в самом процессе разработки — код, в котором свойства объектов заранее неизвестны, сложно поддается как чтению, так и статическому анализу.
khim
intбыл. И эффективность у него была, мягко говоря, не очень.А вот Turbo Pascal 5.5 — отлично работал на XT с 512K, а если очень надо было, то и на PC с 256K (среда не запускалась, но можно было использовать какой-нибудь другой редактор… Turbo Pascal 3.0, к примеру).
А сейчас компьютеры выросли, но мы работаем с «замечательным» гибридами: языками, которые выразительность взяли от Turbo Pascal 5.5, а эффективность — от Smalltalk'а. Потрясающая комбинация.
EvgeniiR
Привычка же )
Кей писал что ST и его парадигма стали «чем-то таким чем нужно учиться», у Девида Веста ещё популярный доклад на эту тему где он маркетинг винит в уничтожении хороших идей.
white_crow
промазал)
white_crow
а сигналы и слоты из Qt подходят под «изначальную концепцию»?
P.S. Скорее всего нет никакой абсолютной изначальной концепции…
Хорошо знать разные подходы и применять лучшие практики для конкретного класса задач.
И понимать, что все развивается, меняется, переосмысливается.
Экспериментам и ошибкам тоже есть место…
0xd34df00d
Кутешные сигналы и слоты — это реализация паттерна publish/subscribe. И реализовывать обмен сообщениями двух конкретных наперёд известных объектов с их помощью считается моветоном.
QtRoS
С каких пор это моветон? Там все API на них, от таймеров до UI. Тот же QML, кстати, весь по сути статический (определен заранее), но все на сигналах. Какое-то очень категоричное суждение получилось...
0xd34df00d
Когда вы пишете код класса
QTimer, вы не знаете, какие клиенты и как им будут пользоваться, и сколько их вообще будет. Там pubsub оправдан (как для почти любого библиотечного класса). Если же вы пишете конечный код с бизнес-логикой, для которого в момент написания известно, кто с кем как взаимодействует, то сигналы и слоты там не нужны (и именно поэтому я написал про «наперёд известных»).А QML вообще отдельная история. Сигналы там — скорее костыль вокруг выразительных способностей языка (в момент компиляции неизвестно, что там в QML будет и какие сигналы/методы будут доступны). Поэтому, кстати, соединиться новым синтаксисом с сигналами QML-объектов у вас не получится, только старые-добрые строки, генерируемые макросами
SIGNALиSLOT.Antervis
ну во-первых, API Qt довольно-таки сильно привязан к сигналам/слотам. Бизнес-логика всё-таки имеет свойство взаимодействовать с GUI/БД/сетью/т.д. Во-вторых, абстрактные «наперед известные» объекты могут жить в разных потоках. Но соглашусь, что пересылать большой поток данных через сигналы/слоты может быть неуместно
0xd34df00d
Ну ещё бы, какой-нибудь
dataChangedдля модельки в MVC — самое оно. Вы не знаете, какие у вас вьюшки будут, сколько их, и так далее. Или там вообще, может, одна модель в другую прокси-модель завёрнута будет.А вот
QNetworkReply::finished— уже унылее, кстати. Я поэтому накорябал обёрточку, которая вQFutureвсё заворачивает. Гораздо удобнее и лучше стало, коммиты с переносом удаляют много строк, а добавляют мало, и некоторые члены классов больше не нужны, и так далее.Про сеть я выше написал.
А для работы с БД у меня тоже QFuture-based API, где надо. С сигналами и слотами состояние размазывается по коду, получается месиво.
Паттерн publish/subscribe про это ничего не знает, это переиспользование деталей реализации сигналов/слотов в кутях для решения другой задачи. Так-то можно и событие послать объекту.
vav180480
Тут было бы интересно услышать про преимущества отправки сообщения объекту (я так понял что канонично-концептуально когда у объекта нет публичных методов вообще) и недостатки вызова публичного метода объекта, даже интересно стало, особливо интересно как автокомплит в IDEшечке будет работать:) Тут главное «не надо 1000 слов, покажи мне код» (с) Из того что я только что прочитал про сие вот тут Objective-C с нуля message-oriented в Objectiv-C это вопрос синтаксиса, а не концепции как таковой просто в function-oriented получается более сахарно и даже на уровне интерпретации это одно и то же
Цитата из вики, выделено болдом мной.
т.е. вместо такого
[object method: 10: 20]
мы просто пишем предварительно определив метод как публичный
object->publicMethod(10, 20)
ROKarpov
Насколько мне известно, в Objective-C можно отправить любое сообщение любому объекту, даже то, на которое он не знает как отвечать, в C++ — можно вызвать только те методы, которые публичные.
vav180480
Ну так и в чем цимес отправки таких сообщений?
evocatus
Позднее связывание, полагаю. Вообще похоже, что для Алана Кея ООП немыслим без динамической типизации.
ROKarpov
Кроме позднего связывания хотел бы добавить о возможности расширения классов «снаружи», в пользовательском коде, без наследования, чтобы обраватывать новые, ранее неизвестные сообщения.
vav180480
Правильно ли я понимаю что например мы имеем в С++ класс в который мы не можем добавить публичный метод и посему вынуждены отпочковать наследующий класс с нужным нам публичным методом, это наследование. Как такое расширение происходит в Objectiv-C с новым сообщением без наследования? Без кода мне не очень понятно.
ROKarpov
Абсолютно правильно, как пример:
Если вас сильно заинтересовал язык, посмотрите доку Яббл о нем.
vav180480
Не то чтобы не заинтересовал — не хОчу, это будет еще в копилочку к тому почему я предпочитаю интерпретируемые языки компилируемым, заэкстендил стороннюю библиотечку и не паришься:)
oracle_and_delphi
Скорость не нужна от слова совсем?
vav180480
Скорость чего? Скорость работы приложения или скорость разработки приложения? Тут вопрос в ресурсах. Что дешевле, прикупить железа или поднанять программистов? Интерпретируемые ЯП взлетели не просто так, а потому что железо подешевело, а трудовые ресурсы подорожали.
VolCh
Интерпретируемые языки взлетели когда железо ещё дорогое было. Из 4-х первых языков высокого уровня, как-то доживших до наших дней, Lisp и BASIC — интерпретируемые, Fortran и Cobol — компилируемые.
oracle_and_delphi
BASIC — изначально учебный язык для коротеньких программ, и после него хорошо учить тот же ForTran.
Хотя, начиная с 1975 года, он стал основным языком для персоналок, где он входил в комплект поставки по умолчанию. То есть да, можно признать, что действительно взлетел.
LISP — тогда требовал специальных LISP-машин более чем вдвое превосходивших по цене тогдашнее типичное топовое железо: топовый компьютер в 1975 году стоил $20 тысяч (самый дешёвый стоил $439), а LISP-машина в те годы стоила от $50 тысяч. И потому имел узкое нишевое применение — там, где были эти LISP-машины (в 1975 году их было два с половиной десятка, и семь тысяч на 1988 год).
Хотя, конечно язык — признаю взлетел, но до современных компьютеров, был в очень узкой нише = в золотой клетке.
third112 Автор
0xd34df00d
А зачем это вообще может понадобиться, методы всякие к имеющемуся типу добавлять?
khim
Для имитации «методов, висящих в воздухе» в стиле CLOS.
А для чего это может понадобиться — ну так можно придумать массу примеров.
Ну например жил-был у вас GUI, рассчитанный на мышь. И захотели вы сделать GUI для телефона. Во многих случаях вы можете просто обрабатывать touch как клик мышкой. Но в некоторых классах (уже существующих!) — хочется другого поведения.
В Objective C — это делается вот через расширения. Ну а в C++/Java — через фабрики-фабрик-фабрик с соответствующей потерей эффективности.
0xd34df00d
Ну так берёте и меняете эти классы, в чём вопрос? Вам же всё равно гуи-фреймворк менять придётся, чтобы там тач-эвенты правильно создавались где надо.
khim
Что значит «берёте и меняете»? Если у вас программа большая, то так просто чужие классы менять не дадут. А если это чужая, готовая, библиотека — то и вообще никак не дадут.
0xd34df00d
А поддержку тач-событий вот вы так просто взяли и запилили в этом случае?
Какой-то нереалистичный пример.
ROKarpov
Допустим, есть какая-то сторонняя библиотека, которую уж очень нравится и хочется использовать. И во всем нашем коде используется типовой код использующий класс из библиотеки, значит выносим в отдельный метод. В той же Java этот метод будет жить в классе-хелпере (не бейте ногами с жавой не сильно знаком). А в обжективе можно расширить класс нужной нам типовой (для нас) функциональностью.
0xd34df00d
Я, наверное, просто никогда не понимал ООП, но чем плохо просто вынести это в отдельный метод, как вы и написали?
EvgeniiR
Расширять своей функциональностью класс из сторонней библиотеки? Странные… кхм… вкусы у вас.
Почему бы не сделать удобный интерфейс объявляющий нужную вам функциональность, и уже в его реализации использовать стороннюю библиотеку, или хотя бы просто декоратором функциональность расширять?
VolCh
final class есть и в интепретируемых )
vav180480
пофиг, задекорируем:)
bm13kk
Концепция именно в этой формулировке крайне тяжела для статического анализа и борьбы со сложностью.
Что хорошо показали Руби и Питон. А также ЯваСкрипт, но там все иначе и ппоэтому плохой пример. В этих языках очень много лапши кода, даже во взрослых библиотеках и фреймворках. Более того, сами философии языков борятся с теми, кто пытается бороться с такой лапшой.
С другой стороны, этот подход хорош на ограниченном множестве сущностей. Как пример, в ОРМах или фасадах модулей.
third112 Автор
А где доказательство, что изначальная концепция лучше «упрощенной»? (м.б., нпр., ЯП, отвечающие изначальной концепции, пользуются большим спросом и т.д.)
TonyLorencio
Я такого не утверждал (ровно как и не стал бы утверждать обратного).
khim
C/C++ — взлетел вместе с Unix, Javascript — это Web, Java — это вообще в чистом виде «каша из топора», когда миллиарды долларов, вбуханных в поделку, которая была хуже альтернатив по всем параметрам, привели к тому, что после многих лет развития — она превратилась-таки в что-то, чем реально можно пользоваться…
Да собственно если бы хорошие языки были популярными, то C и C++ никогда бы не стали языками #2 и #3: они же ужасны!
kalyan_nishchebrod
Класс это — несколько свойств и функций объединенных под одним неймспейсом. Класс может скрывать от внешнего мира свойства и методы, может наследовать поведение от других классов, может переопределять поведение у наследуемых классов. Вот и весь ваш ООП. Зачем делать из этого фетиш и десятилетиями обсасывать это, вообще не понимаю.
Jouretz
Вот такое понимание класса потом и приводит к GodObject'ам, спагетти коду и сотне разных антипаттернов.
Класс это не скопище функций и свойств, это таки логически обособленная единица кода и «обсасывания» временами вполне обоснованными могут быть.
Если вы обернёте весь код в класс MyProgram, это будет не ООП, а вполне себе императивщина
kalyan_nishchebrod
Умение разделять код, с классами и представлением о них, никаким образом не связано. С успехом можно разделять код на функции, всё зависит от повара.
Jouretz
Шта? Либо я чего-то не понимаю, либо где-то тут бред.
Типа да, без разницы будете вы выделять в коде классы и интерфейсы, типы и монады, структуры и трейты либо что-то ещё, основная проблема в понимании что в какой класс/тип/трейт выделить и какие уровни абстракции использовать.
При восприятии классов как обёрток для методов и свойств это, имхо, сложновато будет сделать.
Вся эта чепуха придумана для разумного управления сложностью, и если нагромождения классов и наследований делают код нечитаемым, есть смысл обсуждать и искать решения десятилетиями, не?
kalyan_nishchebrod
Ну не просто обертка, а сущность состоящая из свойств и методов, с определенным поведением. Каким местом это к разделению кода непонятно, GO/Rust классов нет совсем, и ничего.
А так конечно, видите то чего нет, тоже уметь надо.
BOM
О, этот дивный период, когда все мудрости мира у тебя на ладони и вся суета вокруг кажется такой бессмысленной, ведь истина, вот она — проста и интуитивно понятна. Люди до сих пор до нее на додумались и ведут ненужные споры.
Какой там язык сейчас рулит, кстати?
kalyan_nishchebrod
Лучше так, чем напридумывать абстракций и спорить до инфаркта, чья лучше. Проще надо быть.
Язык нужно выбирать в зависимости от задач/платформы. Разве что JS рулит везде, в основном благодаря быдлокодерам.
P.S. Сам я конечно быдлокодер, прошу строго не судить.
habamax
Что в итоге оказалось мифом, а что реальностью? Как ещё одно мнение о том, что такое (или нет) ООП — понятно.
Но тема не раскрыта, как мне кажется.
third112 Автор
Нпр., миф Серебряной пули:
Это широко известный миф:
Еще: Экзистенциальный Вопрос „Что Есть Объект?“»
+ проблемы модельного подхода…
maxxannik
Далее по книге Фредерик Б. пишет о том что под термином ООП скрывается 2 по сути не похожих друг на друга подхода. Один на классах, а второй на компонентах.
Если открыть википедию, то увидите что там уже 3 типа ООП методологии: классы, компоненты и прототипы.
Беда в том что разум 99% программистов ограничен только классами. Они в упор не хотят замечать существование альтернативных ООП концепций.
При этом побеждают на рынке те платформы, которые научились готовить ООП не только на классах, но и грамотно применять компонентные ООП подходы: Angular vs React, Drupal vs WordPress.
Magic_B
В концепции ООП прямоугольник сам должен уметь себя двигать (метод Move(area, dx, dy)) или его должен кто-то уметь двигать (класс Area с методом MoveRect(rect, dx, dy) / Move'T(T, dx, dy))?
Вот когда есть множество вариантов использования и появляются споры. Причина — следствие...
adictive_max
А есть парадигмы, в которых любую задачу предметной области можно решить ровно одним способом?
Magic_B
Если бы для решения одной задачи был бы только один способ, жить было бы не интересно!
А как правильно будет для данного примера? Интересно услышать мнение...
adictive_max
А как удобно — так и правильно. Что удобно, а что нет, определяется в контексте всей архитектуры в целом. Сферовакуумный «hellow world» можно делать как угодно, его цель — не решить прикладную задачу, а продемонстрировать, что «вот так тоже можно».
third112 Автор
Полностью согласен, но ИМХО нужно уточнить, что под удобством понимаем стиль опытного кодера, а не халтуру неуспевающего школьника.
Magic_B
Да, профессионал всегда сможет аргументировать способ решения задачи!
third112 Автор
Да, проблема только в том, что другой профессионал может с ним не согласиться ;)
Magic_B
Как это? Аргументы же есть! )
SadOcean
Я иногда себе могу контраргументов накидать кучу, что уж про остальных говорить
Magic_B
Это очень хорошо! Значит, меняйте решение, если конечно, архитектура, построенная на выбранных с помощью неких аргументов и "принципах" ООП, позволит Вам это сделать…
rjhdby
Даже очевидно плохой и неправильный — на то он и профессионал :D
agalakhov
Вот тут возникает типичная проблема: стиль школьника часто позволяет быстрее сдать выполненную работу. Причем сильно быстрее. Результат будет хреновым, но это заметят далеко не сразу, иногда через годы. Отсюда — поиски технологий (в т.ч. языков), позволяющие опытному кодеру не жертвовать скоростью кодинга ради качества.
third112 Автор
ИМХО байки о супергениальных школьниках — во многом еще один миф. Про поиски технологий согласен.
Magic_B
А при чем здесь препод? Я как препод могу заявить, что не обращаю внимания на стиль. Студенту итак сложно, а если его грузить стилем программирования, он вообще ничего не сделает, плюнет и пойдет в армию! )
third112 Автор
ИМХО стиль — м.б. самое важное, но не буду спорить: у каждого своя метода.
agalakhov
Мы поступали не так. Мы давали на решение задачи много времени, при этом в процесс сдачи включали code review преподавателем. Задача считалась зачтенной, когда студент объяснял причины выбора того или иного способа написания. К самому способу мы не придирались, просто спрашивали. Но порождаемые неудачным написанием опасные баги (вроде утечек памяти) велели устранять.
third112 Автор
Интересно: а если студент пишет комментарий «zapisat dannie v jurnal» и соответственно дает имена типа zapisvjurnal, такое зачтется? — Ведь не переключать регистр «клавы» и не вспоминать английские слова быстрее, если есть проблема с языком.
Magic_B
Думаю, любой преподаватель укажет на это, но на зачет влиять не будет. В случае какой-нибудь школы программирования, конечно подобное недопустимо, как и любые другие общеизвестные правила написания кода.
third112 Автор
ИМХО если у студента программирование профильный предмет, то он должен соблюдать общие правила, но если речь о гуманитарии или о школьнике, то должен понимать, что такой код — неуважение к читателю, прежде всего к преподавателю. Думаю преподавателю нужно экономить собственное рабочее время, а то на всех студентов не хватит. Лучше пусть меньше получат фактических знаний, чем не привыкнут к нормальному оформлению. Но это ИМХО — у меня небольшой опыт преподавания, правда в солидных местах — МГТУ, МГУ.
Magic_B
Речь о среднестатистическом студенте, а не о специальности АСУ в МГУ… Вы в праве иметь собственный подход к преподаванию,, конечно же. Практика покащывает, что студент, который хочет программировать либо спросит, либо разберется, либо к нему другие пожелания преподавателя, в тч те, о которых, говорите Вы.
third112 Автор
ИМХО тут серьезная проблема. В Инете и, в частности, на Хабре много жалоб на понижение качества образования. При этом снижается осознание роли образования — некоторые школьники считают, что сразу после окончания школы смогут писать код за хорошие деньги. И при этом мои знакомые в вузах жалуются, что возрастает давление на преподавателей: стоит не поставить одному студенту зачет — целая делегация отправляется в деканат.
oracle_and_delphi
Замкнутый круг ещё более понижающий качество образования!
Даже на Хабре, полно статей «нах мне математика?!» и «нах мне ВУЗ?!».
adictive_max
third112 Автор
VolCh
Обычно статьи всё же «нах мне, программисту, математика?!» и «нах мне, программисту, ВУЗ?!»
third112 Автор
Ok. Естественное желание многих школьников сразу по окончании школы получать хорошую ЗП, а не тратить 5 лет на вуз. — Вот он и делится с сообществом своими мечтами.
Кто окончил вуз, но условно говоря торгует овощами — не обязательно за прилавком, а м.б. топ-менеджер крупной фирмы и через него каждый день проходят сделки на много тонн овощей и фруктов, видит, что кроме 4 арифметических действий никакая математика ему не нужна.
Но не все собираются всю жизнь торговать овощами и не все смогут найти работу топ-менеджера крупной фирмы. — Как повезет, кому «не повезет» — тому м.б. будет нужна математика :)
skymorp
Присоединяюсь, интересно услышать мнение.
ИМХО (учитывая количество вводных данных): кто-то должен уметь двигать прямоугольник. %)
black_semargl
Если у нас только прямоугольники — то всё равно. А если 100500 разных объектов — то разумно определить что каждый сам лучше знает как себя двигать.
Ну и…
Area.Move(object, dx, dy) => { object.Move(dx, dy) }
(эээ… на каком это я языке написал? ну надеюсь поняли что хотел сказать)
agalakhov
Более важно, на мой взгляд, вот что. Любая сущность, которую вводят в языках программирования, обладает определенными математическими свойствами. Эти свойства, если они удобны, позволяют проверять корректность кода и/или эффективно оптимизировать его при компиляции. Напротив, неудобные свойства приводят к путанице и либо провоцируют ошибки, либо заставляют перегружать код лишней писаниной, чтобы из имеющихся свойств построить желаемые.
В ООП не очень понятно, чем является класс. Это не множество. Это и не класс из математики. Наследование классов не дает ни надмножество, ни подмножество. Поэтому, когда с помощью ООП пытаются выразить типичные для множеств соотношения вроде "окружность — частный случай фигуры на экране", начинают требоваться особые и часто неинтуитивные приемы работы с ООП (часть из них известна как "пэттерны", часть — негласные, но всеми используемые приемы).
Поэтому важно не то, есть в названии языка слово "объектно-ориентированный" или нет, а то, построен ли язык вокруг какой-то удобной аксиоматики. Когда язык строят последовательным добавлением "а вот еще вот эту фичу", получаются внутренние противоречия и парадоксы. Совершенно понятно желание многих людей иметь язык программирования, свободный от парадоксального поведения.
third112 Автор
agalakhov
Ну, содержимое файла — конечное упорядоченное множество пар (номер, байт), операции над содержимым двух файлов, дописывание в файл соответствуют как минимум моноиду (ассоциативность есть, единичный элемент — пустой файл — есть). Имена файлов — граф, дерево. Точного названия для такой штуки в математике скорее всего нет, но многие аксиомы для свойств можно записать сразу.
third112 Автор
agalakhov
Скорее не так: "точного названия в математике пока не придумали". Ничто не мешает написать строгую аксиоматическую теорию файлов. Точно так же, как давным-давно была написана строгая аксиоматическая теория взамен рисования геометрических фигур палочкой на песке. Соответствующий математический объект будет называться "файл".
third112 Автор
napa3um
Почему не пробуют? Разработчики файловых систем только этим и занимаются :).
third112 Автор
И где такая теория? где мат.аналог файла? Нпр., есть матричная алгебра, но о файловой алгебре что-то не слышно.
napa3um
Ок, это не обобщённая теория «любого файла», это описание того, что такое файл, в данной конкретной файловой системе, и какие операции с ним можно или нельзя производить. Каждый из этих стандартов, конечно, хотел бы быть самыми главными, но «файла с научной точки зрения» действительно пока не сочинили :).
P.S.: Вспоминая старые советские учебники по информатике припоминаю что-то такое, думаю, можно найти ГОСТ с описанием сущности «файл в информационной системе».
third112 Автор
Ок, более того, известно много общих алгоритмов работы с файлами, не завязанных на конкретную файловую систему — нпр., внешние сортировки.
samsergey
Конечность, строго говоря, не обязательна:
\ dev\nullтому пример. И вы правильно определили основные структуры, присущие файлу, как математическому объекту.0xd34df00d
Надо ещё добавить временной аспект, и тут вылезут какие-нибудь сложности. И, кстати, не граф и даже не DAG, есть же хардлинки. Можно даже цикл сделать.
Но да, аксиоматизировать можно. Просто непонятно, какую теорию из этого можно будет построить и какие нетривиальные результаты она даст.
black_semargl
не то что можно…
Вот на днях ставил убунту — так там на дистрибутиве папка ubuntu есть линк на корень диска. И в неё можно углубляться бесконечно.
Pand5461
Таки "в основном — чёткие правила, но иногда — исключения" всё равно лучше, чем "пиши как хочешь; есть, конечно, пара правил, но и их нужно воспринимать скорее как правила хорошего тона, а не жёсткий канон".
samsergey
Это называется проблема поиска денотационной семантики. Работа в этом направлении идёт и далека от завершения. Для многих это жуть жуткая и муть мутная, каждый день не нужная. Но для тех кто пишет компиляторы и верификаторы это крутой инструмент.
А файл (POSIX) можно отождествить с анаморфизмом, порождающим свободный моноид, его обработчики — с гиломорфизмами. Файловая система — дерево, или более общий граф, если она реляционная и т.п. Мы используем эти понятия, не зная, что "говорим прозой".
И хотел бы добавить, современная математика огромна. Не торопитесь судить о ней в терминах "никакая математика не определит"… Например, о трех табуретках: теория устойчивости, даже линейная удовлетворительно отличит одно применение от другого.
third112 Автор
см.:Newell, Allen; Simon, H. A. (1976), «Computer Science as Empirical Inquiry: Symbols and Search» (1975 ACM Turing Award Lecture), Communications of the ACM, 19
Можно сделать мат. модель файла, но мы столкнемся с ограничениями моделирования, о которых в статье.
agalakhov
Вот именно. Что характерно, все чаще именно в документации к прикладным библиотекам появляется отдельная главка с денотационной семантикой ее вызовов. И у тех, у кого она есть, обычно все работает круто и продуманно.
oam2oam
конечно же есть абсолютно точное математическое (из мат логики) — «файл» это «кортеж».
Magic_B
Кстати, насчет паттернов. Складывается впечатление, что ООП — есть суть, набор паттернов. Т.е. некие согласованные правила написания кода. Думаю, паттерны и были порождены тем самым множеством вариантов использования в ООП. И люди, пытаются упростить себе жизнь.
Чем больше я писал код в ООП, тем чаще выдумывал паттерны. Честно говоря, устал — надоело! Слез с ООП в итоге в пользу декларативных подходов и простоты Go.
agalakhov
Аналогично, только ушел на Rust и часто пользуюсь функциональным подходом в нем. Rust — потому что я на C++ писал много низкоуровневых оптимизаций, со ссылками на стек и т.д., чтобы без счета ссылок и без сборки мусора, а именно на compile-time, и на Rust это как раз очень хорошо ложится. Go смотрел, хороший язык, но совсем не для моих задач.
Magic_B
Ну идея Go как раз в том и заключается, что хватит выдумывать паттерны! Пишем все одинаково и понимаем друг друга!
agalakhov
В Rust тоже. Только там оставили управление памятью от C/C++, спрятав его под синтаксический сахар, и притащили типизацию в духе Haskell.
0xd34df00d
Не, ну почему.
Это тип в STLC с некоторыми расширениями (записи там, сабтайпинг).
Почему, даёт подмножество, как раз в смысле сабтайпинга.
Они начинают требоваться в момент мутабельности (ИМХО), когда у вас накладываются дополнительные ограничения на ковариантность и контравариантность семантики методов. И да, получаются вопросы о том, кто должен от кого наследоваться между квадратом и прямоугольником, и что для каждого из них в рамках этой иерархии должен делать метод
setWidth.eandr_67
third112 Автор
ЯП Оберон. ИМХО компонентно-ориентированное программирование это мод ООП.
Magic_B
Скорее наоборот, ООП — мод компонентно-ориентированного программирования...
third112 Автор
Ok. Можно сказать и так.
eandr_67
Oberon не имеет классов, объектов и наследования. Это ООП?
JavaScript — не имеет классов и инкапсуляции (впрочем, недавно в JS добавили пародию
на классы, но это только синтаксический сахар). Это ООП?
Полиморфизм? Так он прекрасно реализуется в любом языке, поддерживающем ссылки на подпрограммы — безо всякого ООП.
Так что такое ООП? И как может быть ООП в языке, не имеющем объектов? Может быть, стоит дать определение ООП — прежде чем смешивать мух и котлет?
third112 Автор
borisxm
Что касается высказываний апологетов функционального программирования в адрес ООП, то их аргументы могут выглядеть красиво в ряде ограниченных случаев, но как только дело доходит до реальных применений, где просто невозможно избежать наследования данных и множества композитов, то тут они просто тихо сливаются. Собственно, ООП не отвергает ФП, а просто использует его как часть общей идеологии. В отличие от.
0xd34df00d
Это каких, например?
borisxm
Возьмите любой пример из своей/чужой практики где число предков о объекта больше 2-3х и объект содержит другие как композитные.
0xd34df00d
Я не смог вспомнить ни одного такого примера (если вы не про глубину иерархии, хотя там, впрочем, вспомнить тоже очень тяжело, и наследование там костыль для косячного code reuse).
Содержать другие объекты как композитные вам никто не мешает и в рамках функционального подхода, например. А учитывая, что вы содержите объекты не ради их состояния, а ради их поведения, то всё выливается в обычную композицию функций.
borisxm
Хорошо, когда над объектом нужно выполнить одну-две операции, а когда их больше и нужно, кроме всего прочего, поддерживать/контролировать целостность, связанность и непротиворечивость данных, то ООП становится вне конкуренции, т.к. позволяет держать все в «одном месте», а при поддержке языка, еще ограничить стороннего программиста от желания «поковыряться внутри».
EvgeniiR
Что есть отображение реальных процессов которые нельзя выразить без наследования? Мне в голову пока лишь квадрат с прямоугольником, да собака с млекопитающим и т.п. лезет, и в обоих случаях можно обойтись без наследования.
Наследовнание данных это просто наследование структур, наследованием в ООП обычно называют наследование поведения, и действия производятся объектом, а не «над» объектом
Что и в каком месте, почему при композиции всё не в одном месте?
Если объект большой, может его вообще стоит декомпозировать на логические части с минимальной связностью без наследований и композиций?
borisxm
Причин сомневаться в ошибочности построенной модели нет, т.к. более чем десятилетняя ее эксплуатация не выявила каких-либо недостатков ни в процессах использования, ни в процессах расширения функционала.
Когда композиция является частью объекта, никаких проблем не возникает.
0xd34df00d
Можно пример-то? Я тоже всякое-разное моделировал и проектировал, но там наследование никогда не уходило глубже одного уровня (если интерфейсы не брать в расчёт, а интерфейсы — костыль против отсутствующих тайпклассов так-то). Да и там зачастую алгебраические типы данных бы лучше подошли, но с ними в плюсах работать больно.
К композитам-то как раз никаких вопросов.
Ну так функции над каким-то (непрозрачным) типом данных вполне могут отслеживать все нужные вам инварианты.
И даже приятно выражать все предусловия и постусловия в типах, теория которых для иммутабельных языков развита куда лучше. Но это так, я отклоняюсь.
Это задача другого уровня. Держать всё в одном месте лучше с помощью модулей, и в языках с нормальной модульной системой делать это очень приятно (не зря люди так по окамлу фанатеют с этой точки зрения, хотя мне и в хаскельных недомодулях норм).
borisxm
Функции, не имеющие доступа к данным, по определению могут отслеживать только часть целостности. Функции, которые имеют доступ к данным, могут реализовать все что нужно и называются методами объекта. Нет никакой необходимости отделять их от данных.
На счет модулей спорить не буду, равно как и утверждать, что жить без них нельзя.
0xd34df00d
Ну, то есть, конкретного примера, который можно было бы обсудить, нет. Ну ладно.
То есть, вы ООП ограничиваете обычной инкапсуляцией?
sbnur
Миф — ООП — это серебрянная пуля.
Правда — не каждому дано отлить
AlinaTimofeeva
Полезная статья, спасибо.
LeonidIsakov
Хорошая статья.
0pauc0
Может. Теория автоматического управления. И даже несколькими способами оценки устойчивости.
EvgeniiR
Очередная статья ни о чем, где мифы, где реальность?
По названию подумал что может расскажут для чего и как ООП появлялось, про messaging там и information hiding, но нет, в очередной раз нам что-то пытаются рассказывать про плюсы и минусы мифического инструмента X даже не рассказывая что это за инструмент, приправляя всё это сказами про наследование классов.
third112 Автор
На вопрос про мифы уже ответил выше.
У статьи нет пометки «Tutorial», т.о. предполагается, что читатель в достаточной степени владеет предметом — хотя бы в объеме статьи в Википедии.См. статью — указаны реальные (не мифические) инструменты:
Выше указал, что не «Tutorial». Про Object Pascal (Delphi и т.д..) надеюсь большинство читателей знает.
А где конкретно сказки? ;)
EvgeniiR
> На вопрос про мифы уже ответил выше.
Это не вопрос, а название вашей статьи.
Весь ваш «ответ» сводится к одному предложению — «ООП не решит все проблемы», даже не ваш ответ, а цитата из книжки. Это все что вы хотите донести до читателей? Больше никакой конкретики я не вижу.
> См. статью — указаны реальные (не мифические) инструменты:
Пока в статье используются термины не имеющие однозначной трактовки, и вы не даёте ее в контексте этой статьи, ни о каких конкретных инструментах речи не идёт.
Если статья о наследовании — напишите что статья о наследовании. Причем тут ООП? Я вот ОО-код без наследования пишу.
> хотя бы в объеме статьи в Википедии
Википедия во первых не источник правды, во вторых также однозначной трактовки не даёт.
> Выше указал, что не «Tutorial». Про Object Pascal (Delphi и т.д..) надеюсь большинство читателей знает.
То есть статья не про парадигмы а про ЯП? Кто-то ещё пишет проекты на Паскале?
third112 Автор
Смотрите внимательнее. В самом начале я указал 3 недавних статьи, высказывающие противоположные мнения на данную тему. Это не конкретика? Далее привел «показательный типичный комментарий» и т.д. Что м.б. конкретнее? Вы даже в начале этой конкретики не увидели, поэтому возникает закономерный вопрос: статью читали?
Как такое возможно?: в конкретном ЯП, нпр., Delphi 7 важный термин, нпр., наследование не имеет однозначной трактовки? — Явный абсурд!
Далее у Вас не менее абсурдное заявление:
Кто Вам это сказал? К Вашему сведению Вики делают (пишут, редактируют, обсуждают) в том числе много очень грамотных людей, в том числе спецы мирового уровня. Все, что скзано в вики, должно быть подкреплено ссылками на авторитетные источники. Если что-то ситуативно не подкреплено, то будет подкреплено или будет удалено в ближайшее время.
Подымите первоисточник. Где в указанной статье вики неоднозначные трактовки терминов, которые в моей статье? Вы пытаетесь обвинять меня в отсутвии конкретики, но сами предельно неконкретны, поэтому все Ваши обвинения звучат голословно и бездоказательно.
Много кто пишет. Поиск на Хабре и Гугл Вам в помощь :) Сами какой ЯП знаете? После Ваших заявлений возникает подозрение, что Ваш кругозор дальше одного языка не простирается.
EvgeniiR
> Смотрите внимательнее. В самом начале я указал 3 недавних статьи, высказывающие противоположные мнения на данную тему
Я читал предыдущие статьи, но в данном случае о них речи не идёт. Мне интересно что же вы хотите донести этой статьей, и в этой статье никакой конкретики я не вижу.
Хотя и в предыдущих ее не сильно много то. Так, в комментиках поспорить.> Как такое возможно?: в конкретном ЯП, нпр., Delphi 7 важный термин, нпр., наследование не имеет однозначной трактовки? — Явный абсурд!
Пока не понятно каким образом статья связана с ООП, и этого термина трактовку вы не привели. Единственный «миф» который вы пока что развеяли — что не существует в данном случае серебряной пули, только, не ново это уже давно.
Вопросы про мой кругозор, пожалуй, оставлю за кадром.
third112 Автор
Ответ на этот вопрос м.б. много объяснит. Почему Вы считаетет, что можете не отвечать на мой закономерно возникший вопрос, но требуете ответы у меня на совершенно надуманные вопросы?
Я не обязан приводить трактовку — я привел ссылки на инструменты, где реализованы похожие трактовки и этого достаточно. У меня, нпр., есть «координаты точки» — потребуйте еще трактовку этого термина и, заодно, термина «програмирование» ;))
У Вас, видимо, своеобразное понимание конкретики, если в 4 статьях с большими просмотрами и обсуждениями не увидели конкретики, то помочь Вам не смогу.
EvgeniiR
Вы серьёзно? Причем тут 4 статьи с просмотрами и обсуждениями? Конкретно сейчас действие происходит под одной, одной единственной статьёй, с id 453836, в комментариях под которой мы сейчас находимся, о каких-то других статьях речи не ведётся.
Поэтому статья и бессмысленна. Единственный пример который вы привели — пример наследования. Всё. К термину «наследование» у меня претензий не было.
На википедии гляньте. Они там вполне однозначно описаны.
За сим не вижу смысла продолжать этот диалог и биться о барьер чьей-то психологическей защиты.
third112 Автор
Просто убойный вывод!
+сказано: инкапсуляция, полиморфизм.
Не продолжайте.
TonyLorencio
.