Мифы и реальность ООП


    (Источник)

    Хочу внести свои «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, и эти инструменты генерируют ОО код.

    На мой взгляд, как и в случае любой модели, от модели с применением ООП не стоит ждать, что она чудесным образом раскроет все тайны мироздания. Каждая модель адекватна только в своих узких рамках: «что заложено — то и получим». При этом, согласно требованию естественно-научного подхода, каждый результат, полученный на модели, должен быть перепроверен экспериментально. Но при таких природных ограничениях существуют не всеми осознанные бонусы: к моделированию зачастую возможен примитивно-формальный подход. Так, в случае ООП не нужно пытаться вникнуть глубже возможного при определении объектов и их иерархии. (Аналогично, например, в химии: современные химики знают, что атом не шарик, а химическая связь не стержень фиксированной длины, но это не мешает им использовать шаростержневые модели и структурные формулы.) — Иерархия нужна, чтобы навести порядок в коде модели, но она никогда не будет в точности отвечать гораздо более сложному, чем всякая модель, прототипу.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 205

      +6

      Стоит отметить, что в большинстве ЯП объектно-ориентированный подход упрощен настолько, что от изначальной концепции, когда объектам посылаются сообщения (которые также являются объектами), а первые на них реагируют, остался всего лишь вызов метода, что уже принципиально мало отличается от традиционного процедурного программирования.

      • НЛО прилетело и опубликовало эту надпись здесь
          0
          Вы так говорите, как будто это что-то плохое. Программирование — это не предмет для философских дискуссий, а инструмент для решения задач. Что плохого в том, чтобы из каждого ящика с инструментами взять только самые удобные, не ограничивая себя выбором только какого-то одного самого лучшего ящика?
            0
            Вы так говорите, как будто это что-то плохое.

            взять только самые удобные

            Нет, конечно, это не плохо и не хорошо. Вызов метода просто оказался удобнее, и потому этим мы пользуемся сейчас.

              +2

              Не удобнее, а проще в реализации с приемлемой скоростью. Впрочем, с тех пор уже столько лет утекло, что теперь единственным аргументом за вызов метода остался "привычнее".

                0
                Кроме скорости: чем лучше создавать объект-сообщение конструктором, а потом уничтожать его деструктором? Разве это не потребует больше строчек исходного кода?
                  0

                  Обычно ни конструктор не создаёт объект, ни деструктор его не уничтожает. Первый его инициализирует, втрой — очищает.

                    0
                    В объектно-ориентированном программировании конструктор класса (от англ. constructor) — специальный блок инструкций, вызываемый при создании объекта.

                    На старте программе м.б. неизвестно сколько каких объектов будет нужно. Значит придется динамически создавать (и уничтожать) по мере необходимости в ходе выполнения.
                      +1

                      Именно "при создании", а не "для создания". Конструктор объект не создаёт. Из мэйнстрим языков разве что в JS конструктор может опционально создавать новый объект, а не инициализировать созданный рантаймом

                        0
                        Не понял. Вот конкретный пример:
                        Для этого сделаем следующий простой обработчик события создания основной формы:
                        procedure TMainForm.FormCreate(Sender: TObject);
                        begin
                         dg := TDirectedGraph.create;
                         ug := TUndirectedGraph.create;
                         bg := TBigUndirectedGraph.create;
                         ComboBoxClass.AddItem(dg.ClassName,dg);
                         ComboBoxClass.AddItem(ug.ClassName,ug);
                         ComboBoxClass.AddItem(bg.ClassName,bg);
                         ComboBoxClass.ItemIndex := 0;
                        end;



                        Здесь при создании основной формы создается 1 орграф, 1 неориентированный и 1 неориентированный большой. Позже могу заказать программе с консоли сделать еще 100 орграфов, а предыдущие удалить для экономии памяти. А инициализация dg, ug и bg в другом месте.
                          +1
                          Тут конструктор создаёт ряд других (внутренних) объектов, но не тот объект конструктором которого он является.
                            –1
                            Каких других объектов?
                              0
                              Ну как я понимаю — кем-то создаётся объект типа TMainForm, вызывает свой конструктор, из него FormCreate, в котором создаются три вложенных объекта T*Graph
                                0
                                Вызов TDirectedGraph.create (и т.д.) в обработчике события создания окна — обработчик TMainForm.FormCreate, но create, создающий экземпляр (обект) типа TDirectedGraph, определено в TDirectedGraph.
                            0

                            Я думаю, VolCh справедливо имеет в виду, что основной этап создания объекта — это аллокация памяти для него. В большинстве ЯП этот этап скрыт и не прописывается в конструкторе.

                              0
                              Да. Он скрыт, но память под объект должна выделяться динамически при вызове конструктора.
                              Динамически создаваемые объекты, как правило, размещаются в куче, что менее эффективно, чем размещение их на стеке и, тем более, статическое выделение памяти под них на этапе компиляции.
                                0

                                Не при вызове конструктора, а при вызове оператора new или аналога. Создание объекта, грубо:


                                • выделение памяти под объект и ссылку
                                • создание объекта и ссылки на него
                                • вызов конструктора, с передачей ссылки/указателя в качестве this, self и т. п.
                                • возврат ссылки
                                  0
                                  Ну так выделение памяти и т.д и происходит при вызове конструктора (речь про вызов в исходном коде!). Пока нет вызова прога не знает, что нужен новый объект. Можно в отладчике ассемблерный код посмотреть.
                                  Подробнее
                                  Ставите «бряк» на строке:
                                  dg := TDirectedGraph.create;
                                  Открываете окно CPU и далее шагаете по коду с говорящими именами:
                                  @getMem
                                  call @classCreate
                                  TObject.NewInstance
                                  call TObject.InstanceSize
                                  call @GetMem
                                  call dword ptr [MemoryManager]
                                  SysGetMem
                                  call TObject.Create
                                  и т.д.
                                  0

                                  Оговорка "как правило" вас не смутила?

                                    0
                                    Не. А должна? Почему?
                              +1
                              Из мэйнстрим языков разве что в JS конструктор может опционально создавать новый объект, а не инициализировать созданный рантаймом
                              В С++ изначально тип this не был константным в конструкторе и ему можно было присваивать… но это уже история сегодня, конечно…
                          0

                          Сообщение — это вообще данные, причём тут конструкторы/деструкторы?
                          А лучше тем, что объекты, общающиеся передачей сообщений, не связаны жёстко друг с другом, соответственно на порядки проще становится писать надёжные и масштабируемые системы.

                            +1
                            Сообщение — это вообще данные
                            выше было сказано иное:
                            объектам посылаются сообщения (которые также являются объектами)


                            Возьмем класс TRect из моего примера. Пусть в этом классе будет метод draw, отрисовывающий прямоугольник. Попробуем смоделировать передачу сообщения drawMsg («рисовать») с помощью данных:
                            sendMsg (toRect {куда}, drawMsg {сообщение});
                            

                            Не вижу преимуществ такого кода: ни доп. надежности, ни масштабируемости.
                              –1
                              выше было сказано иное

                              Было сказано, но не мной )
                              Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.


                              Возьмем класс TRect из моего примера.

                              Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги и животные? А авторов, которые такие примеры в книгах используют, разместят на большую доску позора. Всё это настолько безумно далеко от практических целей ООП, что дальше некуда. И на этих вырожденных и абсолютно бесполезных примерах любые преимущества (даже ООП vs ПП) высосаны из пальца.


                              Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
                              Очевидно прокинуть эвент для обработки ряду объектов.


                              sendMsgAsync(eventLogger, event)
                              :ok = sendMsg(eventValidator, event)
                              {:ok, event} = sendMsg(eventEnricher, event)
                              {:ok, response} = sendMsg(eventHandler, event)

                              Пока преимуществ не видно?
                              Но давайте представим, что этим объектам не обязательно находится на одном сервере. В случае, с вызовом метода — это невозможно, все объекты должны быть в памяти процесса, чтобы можно было вызвать их методы. Для передачи сообщений такого ограничения нет, и все 4 объекта из примера могут находиться на разных серверах (масштабируемость из коробки).
                              Теперь представьте, что с объектом logger что-то случилось, например упал с ошибкой. Достаточное ли это условие, чтобы похерить всю обработку эвента? В большинстве систем обработка эвента гораздо важнее его логирования. Но чтобы обеспечить пропуск опциональных шагов, вам придётся каждый из их завернуть в try (мда, ппц как удобно). В случае с сообщениями, вы можете легко сделать sendMsgAsync и не ждать возврата результата, когда он не важен. Бонусом, вы получаете возможность все опциональные действия выполнять в отдельном потоке. А что будет с нашим упавшим из-за какого-то хитрого эвента логгером? А он зареспаунится с исходного состояния, без необходимости восстанавливать что-то после сбоя, без необходимости перемешивать обработку ошибок с бизнес-логикой и т.д.


                              Я в курсе сколько костылей напридумано, чтобы получить похожие результаты в ООП с вызовом методов. Однако для этого достаточно перейти на передачу сообщений между объектами.

                                0
                                Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.

                                См.:
                                Первоначально (например, в том же Smalltalk) взаимодействие объектов представлялось как «настоящий» обмен сообщениями, то есть пересылка от одного объекта другому специального объекта-сообщения.

                                Далее:
                                Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги [...] Всё это настолько безумно далеко от практических целей ООП, что дальше некуда.
                                Рисование графических примитивов очень важная практическая цель любого универсального программирования, нпр., для GUI.
                                А авторов, которые такие примеры в книгах используют, разместят на большую доску позора.

                                Вспомнил Марка Твена:)
                                PERSONS attempting to find a motive in this narra-
                                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.


                                Очевидно прокинуть эвент для обработки ряду объектов.
                                Какой это ЯП? Что означает в ":ok" двоеточие? что значат фигурные скобки в "{:ok, event} = sendMsg(eventEnricher, event)"?

                                В случае, с вызовом метода — это невозможно, все объекты должны быть в памяти процесса, чтобы можно было вызвать их методы. Для передачи сообщений такого ограничения нет,
                                Чем это отличается от передачи событий ОС, нпр., Виндов ХР? Для обменов клиент-сервер обычно применяют технологии типа COM и, даже, CORBA.
                                Есть еще контрактное программирование…

                                  –2

                                  Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:


                                  1. Everything is an object.
                                  2. Objects communicate by sending and receiving messages (in terms of objects).
                                  3. Objects have their own memory (in terms of objects).

                                  Как видите, тут нет никакого требования чтобы сообщения были объектами. Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.


                                  Рисование графических примитивов очень важная практическая цель любого универсального программирования, нпр., для GUI

                                  Да что вы говорите… и что же в GUI есть кроме прямоугольников, которые по-хорошему рендерит ОС (мы же хотим нативный look-n-feel, не так ли), используя процедурный код?
                                  Да и если вы не разработчик GUI framework, то это вообще вас не касается. Вы ООП для бизнес-логики используете, а не для отрисовки кнопочек.


                                  Чем это отличается от передачи событий ОС, нпр., Виндов ХР? Для обменов клиент-сервер обычно применяют технологии типа COM и, даже, CORBA.

                                  Мы тут ООП обсуждаем, а не Виндов ХР. Вы предлагаете обмен сообщениями между объектами вести не средствами ЯП, а средствами ОС? Ну и я же написал, что я в курсе наличия извращений разных сортов, в том числе типа 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 (ближе всего к классическому ООП)


                                  Какой это ЯП? Что означает в ":ok" двоеточие? что значат фигурные скобки в "{:ok, event} = sendMsg(eventEnricher, event)"?

                                  Можете считать это псевдокодом. Вчитайтесь в суть, а не в синтаксис. Фигурные скобки — это кортеж. :ok — статус, проверяемый через pattern-matching. Если будет не :ok, то дальше код не пойдёт.


                                  P.S. Почитайте статью, которую вы упустили из виду.

                                    0
                                    Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:

                                    Everything is an object.
                                    Objects communicate by sending and receiving messages (in terms of objects).
                                    Objects have their own memory (in terms of objects).
                                    Из какого классического первоисточника это определение? Я встречал его во многих источниках — интересно какой был первый ;)
                                    По сути:
                                    Everything is an object.
                                    В принципе я не против содержательной философии, но тут она явно избыточна и только наводит тумана. Нпр., я бы не стал называть переменную Х вещественного типа объектом. И я бы не назвал константу 3.14 обектом. И я бы не сказал, что операция присваивания переменной Х этого значения есть операция инициализации объекта:
                                    X := 3.14;
                                    И никакой инкапсуляции. И где тут сообщение? Но, наверное, есть подходы, где «Everything is an object.»
                                    Как видите, тут нет никакого требования чтобы сообщения были объектами. Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.
                                    С этим не спорю.
                                    Да и если вы не разработчик GUI framework, то это вообще вас не касается. Вы ООП для бизнес-логики используете, а не для отрисовки кнопочек.
                                    ИМХО термин «бизнес-логика» размытый, плохой, нелепый. ИМХО очевидно: бизнес это деньги. В явном виде деньги не во всяком коде, а если и есть, нпр., в коде игры, то галактические кредиты 3300 г. — не те это деньги, которые хочет кодер) Поэтому ИМХО лучше использовать синоним: логика предметной области (domain logic). Иногда отрисовка «кнопочек», т.е. элементов контроля GUI это логика предметной области: нпр., клетки периодической таблицы (не обязательно прямоугольные).
                                    Ну и я же написал, что я в курсе наличия извращений разных сортов, в том числе типа COM и CORBA
                                    Столь резкое утверждение нуждается в строгом доказательстве. (Возможно ли математически строго доказать, что технология Х — извращение? — Термин «извращение» не мат. термин, поэтому думаю, что это не более чем субъективные оценочные суждения, как с Вашей, так и с моей стороны. Большого значения они не имеют.)
                                    неужели это кто-то до сих пор использует?
                                    См.:
                                    В 2002 году была официально выпущена платформа Microsoft .NET, которая на сегодняшний день объявлена Microsoft рекомендуемой основой для создания приложений и компонентов под Windows. По этой причине в .NET включены и средства, позволяющие обращаться к компонентам COM из приложений .NET, и наоборот. По словам представителей Майкрософт, COM (точнее, COM+) и .NET являются отлично взаимодополняющими технологиями.

                                    Далее:
                                    Можете считать это псевдокодом. Вчитайтесь в суть, а не в синтаксис. Фигурные скобки — это кортеж. :ok — статус, проверяемый через pattern-matching. Если будет не :ok, то дальше код не пойдёт.
                                    Т.е. никакой из существующих ЯП такой механизм не использует? Попытаюсь расшифровать этот псевдокод:
                                    sendMsgAsync(eventLogger, event)
                                    :ok = sendMsg(eventValidator, event)
                                    {:ok, event} = sendMsg(eventEnricher, event)
                                    {:ok, response} = sendMsg(eventHandler, event)

                                    Посылаю асинхронно сообщение event через eventLogger. Если функция sendMsg возвращает ложный статус — остановить программу. Кортежам «статус, событие» и «статус, отклик» присвоить «обогатитель» (?) события и хандлер события. И зачем нам такие кортежи? Полный туман:

                                    1) sendMsgAsync посылает сообщение определенному объекту (объектам) или всем объектам в инете?
                                    2) Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?
                                    3) Должен быть единый список сообщений, понятный всем объектам?
                                    4) Какой формат сообщения? (сколько в нем полей, символов, целых и нецелых чисел и т.д.)
                                    5) Если сообщения в инете, то они должны шифроваться для безопасности?

                                    Много чего есть…
                                    Я не про всё, что есть. А про ОО подход, который представляется ИМХО более совершенным, чем обмен сообщениями.
                                    Почитайте статью, которую вы упустили из виду.
                                    Не упустил, но и при повторном прочтении не увидел там особо интересной информации по теме. Речь там о незнакомом мне ЯП «в ответ на вопрос о парадигме языка». М.б. кто знает этот язык — тому интересно. А у меня даже общего представления не сложилось. Есть много статей на подобные узко-специальные темы, почему я должен был не упустить и упомянуть именно эту?
                                      –1
                                      Из какого классического первоисточника это определение? Я встречал его во многих источниках — интересно какой был первый ;)

                                      Тот, кто ввёл термин ООП (Алан Кэй), тот и был первым, очевидно же. Цитату можно найти в The Early History Of Smalltalk, но скорее всего она и раньше публиковалась в статьях на эту тему.


                                      В принципе я не против содержательной философии, но тут она явно избыточна и только наводит тумана.

                                      Давайте я вам расшифрую, "Everything is an object" означает только одно: никакой код, из написанного вами, не может выполняться вне объекта. Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.


                                      Иногда отрисовка «кнопочек», т.е. элементов контроля GUI это логика предметной области: нпр., клетки периодической таблицы (не обязательно прямоугольные).

                                      Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете? В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев. Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. А не в том, что кружочки никогда не понадобятся. Может и понадобятся пару раз за 10 лет… Кто вас знает, может вам даже кролики, унаследованные от Animal, понадобятся для периодической таблицы. Вот только в ежедневной работе программисты другими вещами занимаются.


                                      Термин «извращение» не мат. термин

                                      В контексте данной дискуссии этот термин используется лишь для сокращения "делать простые вещи сложным и нестабильным способом", в простонародье "через задницу", например: имея 2 руки, управлять трекпадом ногой.
                                      Кстати, каким боком цитата про то, что 17 лет назад в .NET включили средства для работы с COM+, доказывает актуальность CORBA в наши дни?


                                      Т.е. никакой из существующих ЯП такой механизм не использует?

                                      Использует (напр. Erlang, Elixir, LFE и т.д.), но не буду же я вас через комментарии новому ЯП учить. Это к вашему изначальному непониманию чем сообщения удобнее методов отношения не имеет.


                                      sendMsgAsync посылает сообщение определенному объекту (объектам) или всем объектам в инете?

                                      Разумеется конкретному, я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.


                                      Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?

                                      И что?


                                      Должен быть единый список сообщений, понятный всем объектам?

                                      Нет.


                                      Какой формат сообщения? (сколько в нем полей, символов, целых и нецелых чисел и т.д.)

                                      Любой. Any Data.


                                      Если сообщения в инете, то они должны шифроваться для безопасности?

                                      Да, такая опция есть. Однако, даже если объекты на разных машинах, они не обязательно выставляются в инет, есть локальные сети в пределах одного ДЦ для этого.


                                      Есть много статей на подобные узко-специальные темы, почему я должен был не упустить и упомянуть именно эту?

                                      Потому что она на тему ООП. И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk и c Erlang/Elixir. А до тех пор вы будете не в теме. То, что вам на текущем этапе знакомо это не ООП, это попытка добавить часть идей ООП в Pascal.

                                        –1
                                        Прежде всего:
                                        Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. [...] Вот только в ежедневной работе программисты другими вещами занимаются.
                                        Не говорите за всех. Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются. В то же время именно научные учреждения обеспечивают прогресс в программировании. Т.о. это с Вашей стороны «диверсия» приземлять всё до уровеня промышленной разработки :)

                                        Далее слишком много путаницы
                                        Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете?
                                        Вижу, что не потрудились открыть статью — там не так много рисунков. Этот Вы бы заметили.
                                        В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев.
                                        Абсурд так говорить о задаче для образования.
                                        Это к вашему изначальному непониманию чем сообщения удобнее методов
                                        Или к Вашему изначальному непониманию, чем методы удобнее сообщений ;)
                                        Цитату можно найти в The Early History Of Smalltalk
                                        А выше сказали:
                                        Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.

                                        И опять сказали:
                                        И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk

                                        Так имеет Smalltalk отношение к сути вопроса или не имеет? — Похоже, что Вы сами запутались :)
                                        BTW:
                                        Первым языком программирования, в котором были предложены основные понятия [ООП], впоследствии сложившиеся в парадигму, была Симула

                                        Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.
                                        Вот случай мифа о котором в статье:
                                        метафора, которую попытались возвести в статус религии.
                                        Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП. А еще говорите о промышленной разработке!
                                        я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.
                                        У Вас
                                        sendMsgAsync(eventLogger, event)

                                        Где у меня eventLogger?
                                        Более того Вы ж сказали, что возьмете не мой, а свой пример:
                                        Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
                                        Очевидно прокинуть эвент для обработки ряду объектов.

                                        Опять запутались!
                                        И «прокинуть эвент для обработки ряду объектов» это не
                                        Разумеется конкретному,

                                        Снова запутались?!

                                        Далее я спросил:
                                        Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?

                                        Вы ответили классически вопросом на вопрос:
                                        И что?

                                        Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет. Не буду комментировать такой абсурд.

                                        Т.о., к сожалению, никаких доводов, кроме исторических, про преимущество обмена сообщениями в ООП я не услышал. Скорее услышал контрдоводы. Сейчас основное направление ООП не обмен сообщениями между объектами. В статье я исходил из этого основного направления и продолжу его придерживаться.
                                          –1
                                          Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются.

                                          Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.


                                          Так имеет Smalltalk отношение к сути вопроса или не имеет?

                                          Есть абстрактная идея ООП, а есть её реализации. Поскольку вы хотите не только теорию, но и конкретику, то вам придётся ознакомиться и с реализациями ООП:
                                          Smalltalk — классическая class-based реализация ООП
                                          Erlang/OTP — actor-based реализация ООП


                                          При этом то, что справедливо для конкретной реализации, не всегда справедливо для парадигмы как таковой.


                                          Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП.

                                          Да в принципе никакое, пока вы сами по себе что-то там пишете, можете хоть своим личным ООП руководствоваться. Но раз взялись писать статью, то потрудитесь хоть немного разобраться в теме, прежде чем писать о ней. И нет, прочитать одну статью на википедии недостаточно.


                                          У Вас
                                          sendMsgAsync(eventLogger, event)

                                          Где у меня eventLogger?
                                          Более того Вы ж сказали, что возьмете не мой, а свой пример

                                          OMFG, вы читать вообще умеете, я же русским языком написал, что взял синтаксис из вашего примера, чтобы вам понятнее было. Напоминаю:
                                          sendMsg ({куда}, {сообщение});


                                          И «прокинуть эвент для обработки ряду объектов» это не
                                          Разумеется конкретному,

                                          Каждая строка отправляет сообщение конкретному объекту, а все вместе они образуют ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)


                                          Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет.

                                          О чём вы вообще говорите? Какие миллионы компов всей Земли? Хоть это и происходит, но это вообще не в тему обсуждения. Вы вообще понимаете, что такое горизонтальное масштабирование системы? Или кроме desktop-приложений на Delphi ничего не делали?

                                            0
                                            Ваше упорство в попытках донести свою позицию могло бы вызвать определенное уважение, если бы не два обстоятельства: по-детски мелочные нападки (на которые тратите значительную часть своих комментов) и слепой фанатизм.

                                            Пример нападок:
                                            Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.

                                            И это Вы заявили при явном отсутствии информации (когда другой на Вашем месте промолчал бы до получения большей информации). Будет Вам известно, что те самые кружочки могут обозначать вершины молекулярных графов или атомы. А изучение таких графов позволяет, нпр., проектировать вещества с заранее заданными свойствами, нпр., новые лекарства.

                                            Что касается фанатизма, то здесь первым делом нужно отметить Вашу убежденность в превосходстве промышленной разработки над научной и в том, что сообщения удобнее методов. Вы даже не понимаете что тут доказывать — произносите слово «логер» и Вам кажется, что каждый должен склоняться перд ним в трепете. А между тем Вы даже задачу толком не сформулировали. Так и осталось непонятным зачем этот ряд:
                                            ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)


                                            М.б. и попытались что-то объяснить, но с объяснениями, как и с доказательствами у Вас явно не получается. Про свой вывод о Вашей трактовке ООП я уже сказал в предыдущем комменте.
                                              0
                                              Будет Вам известно, что те самые кружочки могут обозначать вершины молекулярных графов или атомы. А изучение таких графов позволяет..

                                              Вы в упор не читаете, что вам пишут. Речь была про примеры, на которых зачастую объясняют ООП в учебниках. Вы сначала убеждали, что они прекрасны, и ничего сложнее для понимания ООП не надо. А теперь обижаетесь на простые логические выводы из ваших же слов. Я же вам пытаюсь объяснить, что ООП придумали не для простых задач, а для того чтобы упростить решение сложных. Поэтому именно сложные задачи необходимо рассматривать и в учебниках, иначе у людей формируется искажённое понимание ООП.
                                              Что касается графов, их изучение и отрисовка — это 2 несвязанные задачи.


                                              первым делом нужно отметить Вашу убежденность в превосходстве промышленной разработки над научной

                                              Вообще ничего подобного. Научная разработка она просто другая. Зачем сравнивать тёплое с мягким. Единственный факт, на который стоило бы обратить внимание, что в научной разработке занято на порядок, а то и на пару порядков, меньше людей. Поэтому при обсуждении примеров для массовых учебников и статей, разумнее опираться на промышленную обработку. Это не вопрос какого-то мнимого превосходства, это просто вопрос здравого смысла.


                                              Так и осталось непонятным зачем этот ряд

                                              Вы английский знаете? У каждого из этих объектов одна ответственность, которая выражена в его названии.
                                              Можно было бы тоже статью накатать с подробной расшифровкой, но я не вижу в этом смысла. Кто сталкивался с подобным классом задач, тот и так поймёт что я написал. А кто не сталкивался — ну может им и не надо. Собственно, может им и ООП не надо.

                                                –2
                                                Много байтов не на тему статьи:
                                                Что касается графов, их изучение и отрисовка — это 2 несвязанные задачи.
                                                Кто Вам сказал такую абсурдную вещь? Если изучаете конкретный граф, то его ввести в комп сначала надо. И как быть? Писать на бумажке матрицу смежности или сразу на экране рисовать, а матрицу комп сообразит?

                                                Я же вам пытаюсь объяснить, что ООП придумали не для простых задач, а для того чтобы упростить решение сложных.
                                                А я Вам пытаюсь объяснить, что если можно упростить задачу, для объяснения — это надо сделать. Есть такой риторический прием добавить туману, чтобы сложнее понять было, а начинаешь разбираться — задачка оказывается элементарной. И, опять, кто Вам сказал, что ООП придумали не для простых задач? Во многих задачах ООП используется для очень простого GUI. Да и в целом, простых задач повсюду решают гораздо больше, чем сложных.

                                                именно сложные задачи необходимо рассматривать и в учебниках
                                                Уверен, что большинство учителей с Вами не согласятся, т.к. принцип «от простого к сложному» хорошо себя зарекомендовал.

                                                А теперь обижаетесь
                                                Я не обижаюсь. А только привел пример Ваших нападок не на тему статьи.

                                                Научная разработка она просто другая. Зачем сравнивать тёплое с мягким.
                                                Что значит «просто другая»? Там что: другие компы, другие ОС, другие ЯП?

                                                Единственный факт, на который стоило бы обратить внимание, что в научной разработке занято на порядок, а то и на пару порядков, меньше людей.
                                                Да, и эти люди обычно решают наиболее сложные задачи.

                                                Поэтому при обсуждении примеров для массовых учебников и статей, разумнее опираться на промышленную обработку.
                                                Нет. В пром. разработках очень много тривиальных задач.

                                                Вы английский знаете?
                                                Да.

                                                У каждого из этих объектов одна ответственность, которая выражена в его названии.
                                                Названия осмыслены, но смысла задачи они не раскрывают.

                                                Можно было бы тоже статью накатать с подробной расшифровкой, но я не вижу в этом смысла. Кто сталкивался с подобным классом задач, тот и так поймёт что я написал.
                                                С тем же неуспехом можно написать пару строк с именами input, output и сказать: кто сталкивался — тот поймёт.


                                                  0
                                                  Если изучаете конкретный граф, то его ввести в комп сначала надо.

                                                  Так ввести (в виде данных), или вывести на монитор в виде картинки? Вы уж определитесь там..


                                                  И, опять, кто Вам сказал, что ООП придумали не для простых задач?

                                                  Это просто факт. Читайте первоисточники.


                                                  Что значит «просто другая»? Там что: другие компы, другие ОС, другие ЯП?

                                                  То и значит. Разные условия, разные цели, разные типы задач, разные процессы разработки. Да и языки другие, для научной разработки лучше всего подходят Haskell, Idris, Matlab, Fortran, etc. Julia вон недавно завезли, не пробовали ещё?
                                                  А ООП вам там в подавляющем большинстве задач нафиг не сдалось, если честно. Научная разработка — вотчина ФП (чистая математика, самый сок) и ПП (там где скорость критична, а алгоритмов с неизменяемыми данными не хватает).


                                                  Да, и эти люди обычно решают наиболее сложные задачи.

                                                  Это смотря по каким критериям измерять сложность. Вы лишь сравниваете что зеленее? тёплое или мягкое?
                                                  Посади тех же людей, которые решают сложные научные задачи, писать промышленный проект средней руки, и они облажаются по полной. Так же как и в обратную сторону.


                                                  В пром. разработках очень много тривиальных задач.

                                                  Можно подумать в научных мало… Все расчёты сводятся в конечном итоге к большому кол-ву тривиальных задач.
                                                  Это неважно. Важно, что нетривиальных задач тоже много.

                                                    –1
                                                    Так ввести (в виде данных), или вывести на монитор в виде картинки?
                                                    Когда Вы картинку в Фотошопе редактируете, Вы эту картинку на экране видите? Чем отличается картинка графа? (Только редактор другой).
                                                    Это просто факт. Читайте первоисточники.
                                                    Лет 20-30 назад, кто-то из теоретиков написал, а Вы ему поверили?

                                                    Далее мне стало скучно отвечать на столь примитивную риторику.
                                                      +2
                                                      Лет 20-30 назад, кто-то из теоретиков написал, а Вы ему поверили?

                                                      Далее мне стало скучно отвечать на столь примитивную риторику.


                                                      На кто-то из теоретиков, а автор термина, «мифы» о котором вы решили «развеять», и не только 20 и 30 лет назад, а он до сих пор жив и до сих пор имеет мнение по этому поводу.

                                                      Постыдились бы лучше своего невежества да нежелания разбираться в теме и слушать людей вокруг, чем демагогию разводить, да пытаться уже 3-их собеседников выставить непонимающими путем выдергивания их фраз и подмены контекста.
                                                        –3
                                                        Если человек — автор термина, то мы должны безоговорочно верить всему, что он сказал? Чистейшей воды догматизм, не возможный в IT. Стыдитесь!

                                                        слушать людей вокруг

                                                        Т.е. Вас, который ранее уже попрощался и зачем-то вернулся, и Source, который ушел из темы в обсуждение моей персоны? ;) — Прекрасный ассортимент! А главное многочисленный :)))
                                                          0
                                                          > «Если человек — автор термина, то мы должны безоговорочно верить всему, что он сказал?»

                                                          1. Нет, я лишь знаком с его мыслями, и знаком с текущим, «популярным» ООП и понимаю почему оно таковым не является. Вам, насколько я помню, приводили пример статьи с комментарием от Армстронга, да и в целом информация гуглится. А банально, не знание кто такой Алан Кей, со стороны автора который решил миру про ООП вещать это невежество.

                                                          2. Догматизма в моих высказываниях не было. Вы снова пытаетесь подменить смысл моих слов на очевидно абсурдный и опровергать мнение которого я не высказывал. Чистейшая демагогия.
                                                            –2
                                                            Эта статья не про историю ООП, не про то кто что когда сказал. Прекратите здесь флудить, EvgeniiR .
                                                              0

                                                              Полностью согласен, я ведь изначально и писал что эта статья не про ООП :)

                                                                +1

                                                                Вот с этим не поспоришь :)
                                                                Жаль только в заголовке оно упоминается )))

                                                                  +2
                                                                  А нельзя ли, хотя бы на Хабре, сделать так, чтобы название статьи ну хоть чуточку коррелировало бы с её содержанием?
                                                                    –1
                                                                    И что не коррелирует? (В названии нет слова «история»).
                                                              0

                                                              Как минимум, мы должны безоговорочно верить его определению термина и объяснению зачем он нужен. Если не верим, то просто надо придумать другой термин.

                                                                –1
                                                                А речь шла не про определение, а про утверждение, что ООП придумали не для простых задач.
                                                                мы должны безоговорочно верить его определению

                                                                Почему? Учитывая, что:
                                                                ООП имеет уже более чем сорокалетнюю историю, но, несмотря на это, до сих пор не существует чёткого общепринятого определения данной технологии[14]. Основные принципы, заложенные в первые объектные языки и системы, подверглись существенному изменению (или искажению) и дополнению при многочисленных реализациях последующего времени. Кроме того, примерно с середины 1980-х годов термин «объектно-ориентированный» стал модным, в результате с ним произошло то же самое, что несколько раньше с термином «структурный» (ставшим модным после распространения технологии структурного программирования) — его стали искусственно «прикреплять» к любым новым разработкам, чтобы обеспечить им привлекательность.
                                                                  +2

                                                                  Тем более. Если определение могло изменитья и исказться и теперь его начальное значение "потеряно", то вот ЗАЧЕМ эту штуку придумали измениться не могло

                                                                    –1
                                                                    Зачем придумали — вопрос чисто исторический и мало кому интересный для практики, а вот зачем хотели использовать и зачем используют сейчас запросто могло измениться. Нпр., инет придумали явно не для того, чтобы фотки котиков в соцсетях размещать, а ЭВМ не для того, чтобы криптовалюту майнить. М.б. ООП придумали исключительно для сложных задач (еще вопрос, что тогда считали сложной задачей), но тогда не было современных IDE, а потом оказалось, что даже простенькую форму с одной кнопкой очень удобно генерировать автоматом, где код будет ОО. Теперь Вы можете сколько хватит сил призывать правильно использовать ООП только для сложных задач — Вас никто не станет слушать ;))
                                                                      0
                                                                      оказалось, что даже простенькую форму с одной кнопкой очень удобно генерировать автоматом, где код будет ОО.

                                                                      Ну ведь всего пару часов назад речь шла о том что нет однозначного определения. ОО-код в формочке никакое на самом деле не ООП в том виде, в котором оно задумывалось, это просто использование классов для структурирования кода, ООП в классическом его определении от классов не появляется.

                                                                    +1
                                                                    А речь шла не про определение, а про утверждение, что ООП придумали не для простых задач.

                                                                    Если про это не написали в русской Википедии на странице про ООП, то для вас это неочевидно?
                                                                    Я бы даже сказал, что не слишком громким обобщением, будет сказать, что в программировании уже лет 70 как ничего не придумывают для простых задач. Основной драйвер развития парадигм и инструментария — борьба со сложностью.


                                                                    И именно на этой борьбе построили удачные маркетинговые компании, которые реализовали небольшое подмножество идей ООП, типа того же C++. Да с него плевались те, кто придумал ООП, писали "что за хрень?", но маркетинг сделал своё дело. Но это 35 лет назад можно было на что угодно навесить ярлык ООП, лишь бы продать. Сейчас любой желающий может ознакомиться с оригинальным описанием парадигмы, осознать масштабы концептуальных искажений в мейнстрим языках и сделать выводы. И практически применимые выводы, потому что ООП — это не технология, а парадигма — совокупность идей и понятий, определяющих стиль написания программ. Как только поймёте парадигму, сможете начать её применять в любом языке.

                                                                      –2
                                                                      Вы уже повторяетесь. Но главное, что высказались и можно успокоиться, главное — не волнуйтесь. Я уже ответил выше на другой коммент о том же самом:
                                                                      Теперь Вы можете сколько хватит сил призывать правильно использовать ООП только для сложных задач — Вас никто не станет слушать :))
                                                                        +1
                                                                        Теперь Вы можете сколько хватит сил призывать правильно использовать ООП только для сложных задач — Вас никто не станет слушать :))


                                                                        Кто-то не станет, а у кого-то ещё осталось собственное мышление и желание разобраться в вопросе, а не наследовать круг от овала потому что так в институте на курсе по «ООП» научили.

                                                                        По поводу того что формочки это не ООП, это просто классы я писал, и против их использования из комментаторов никто не выступал но вы как всегда пропустили это мимо себя.
                                                                          0
                                                                          Возможно, я что-то пропустил, возможно, что Вы недостаточно понятно высказались. Формат комментария не идеален для формирования целостной картины. Поэтому напишите статью на Хабр, где подробно и обоснованно раскажете о своем понимании ООП. А здесь начинать спор по второму кругу смысла не будет.
                                                        0
                                                        Поэтому именно сложные задачи необходимо рассматривать и в учебниках
                                                        Эта проблема есть в обучении чему угодно. Всякие правила работы на токарном станке тоже объясняются на простых примерах, хотя они разработаны для сложных.

                                                        Ну просто потому что во время обучения время дорого и сложные примеры рассмотреть сложно.

                                                        Потому такая разная зарплата у людей, только что отучившихся, и у людей с опытом хотя бы в год-два.

                                                        иначе у людей формируется искажённое понимание ООП.
                                                        Если у человака «гуманитарный склад мышления», то он везде найдёт способы всё неправильно проинтерпретировать:
                                                        Глупо из-за этого тратить полгода на изучение одного сложного примера, вместо того, чтобы пройти целый курс.

                                                        К тому же на практике простые примеры встречаются чаще.

                                                        Кто сталкивался с подобным классом задач, тот и так поймёт что я написал. А кто не сталкивался — ну может им и не надо. Собственно, может им и ООП не надо.
                                                        Там надо студентам рассказывать про ООП или не надо? И если надо — то стоит ли начать с логгеров до того, как они крожочек на экране смогли нарисовать?
                                                          0

                                                          Имхо, не стоит ничего объяснять на искусственных примерах. И да, это общий вопрос для любых концепций. Всегда можно найти достаточно простой пример, но при этом адекватный и практически применимый.


                                                          Проблема в примерах с фигурами и животными, в том, что они сами по себе являются примерами непонимания как и зачем применять ООП, примерами того, как делать не надо. При этом люди на них осваивают это самое ООП. А потом, когда они набираются опыта, пишут статьи типа "Чем быстрее вы забудете ООП, тем лучше для вас". А всё потому, что изначально учились на дрянных и совершенно неадекватных примерах.
                                                          Примеры разбора их неадекватности: 1, 2


                                                          ООП — полезная парадигма, но только если понимать зачем она была создана и для чего. А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.

                                                            0
                                                            Всегда можно найти достаточно простой пример, но при этом адекватный и практически применимый.
                                                            Дык пресловутые прямоугольники и окружности — вполне практический и применимый пример. Любой векторный редактор поверх них устроен. Конечно не каждый студент будет делать в своей работе векторный графический редактор… Ну так то же самое можно про что угодно сказать.

                                                            Проблема в примерах с фигурами и животными, в том, что они сами по себе являются примерами непонимания как и зачем применять ООП, примерами того, как делать не надо.
                                                            А как, извините, «делать надо». Вот хотите вы открыть SVG-файл и как-то научиться отображать его — как вы программу структурирует? Неужели без классов «линия» и «дуга окружности» обойдётся? Ну расскажите как это должно быть устроено — интересно же.

                                                            А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.
                                                            Ну если вы, вдруг, «поняли дзен» — то расскажите как ваш «правильный» Inkscape будет отличаться от реально существующего. Только не надо к логгерам переходить, я вас умоляю: векторные редакторы тоже нужны — и если ваш ООП не позволяет их создать — то зачем это всё нужно?
                                                              0
                                                              Конечно не каждый студент будет делать в своей работе векторный графический редактор… Ну так то же самое можно про что угодно сказать.

                                                              Как сказать… Есть классы задач, которые решаются постоянно, ежедневно в тысячах компаний по всему свету, просто потому что универсального решения нет или пока не нашли, но есть универсальные принципы и подходы к их решению. И именно их было бы гораздо полезнее рассматривать в учебных целях. Нечто подобное рассматривают в книгах про паттерны проектирования.
                                                              Вот только это сложный и путанный путь: сначала объяснить ООП так, чтобы никто не понял зачем оно, а когда задолбается, начал паттерны изучать или переизобретать.
                                                              Обратите внимание, почти все паттерны выделяют объекты по поведению (поведение + данные, необходимые для его реализации), а почти все учебники и статьи для начинающих продолжают нести дичь про объекты реального мира и про то, что объект — это модель, это данные и всевозможные действия над этими данными (= фундаментальная ошибка понимания ООП).


                                                              P.S. Вы всерьёз думаете, что формат комментариев подходит для обсуждения создания векторного редактора с нуля? Мало того, что это практически бессмысленная задача (у вас бюджета не хватит подвинуть конкурентов), так она ещё и огромна.
                                                              Но раз уж вам захотелось дзена, то почитайте исходники того же Inkscape и ответьте на вопросы: Почему класс Circle не наследует от класса Shape? И не содержит метода draw? Авторы Inkscape не дураки, чтобы делать так, как описано в "учебниках" по ООП.

                                                                0
                                                                Но раз уж вам захотелось дзена, то почитайте исходники того же Inkscape и ответьте на вопросы: Почему класс Circle не наследует от класса Shape? И не содержит метода draw?
                                                                Ответ, вообще-то, очевиден — только не таков, каким он вам кажется.

                                                                Авторы Inkscape не дураки, чтобы делать так, как описано в «учебниках» по ООП.
                                                                Авторы Inkscape, вообще-то, начинали с исходников Sodipodi, созданном на языке C без использования ООП.

                                                                Разумеется когда вы добавляете ООП в уже существующий код — ваши руки оказываются «связанными».
                                                                  0
                                                                  Ответ, вообще-то, очевиден — только не таков, каким он вам кажется.

                                                                  Если вы намекаете, что ответ — "исторически сложилось", то это неправильный ответ.


                                                                  Авторы Inkscape, вообще-то, начинали с исходников Sodipodi, созданном на языке C без использования ООП.

                                                                  Ох, как же вы живёте то теперь со знанием, что векторный редактор можно и без ООП написать xD


                                                                  Кстати, в C вполне возможно использовать ООП (не забывайте, что это парадигма, и что наличие классов — не является её требованием)


                                                                  Разумеется когда вы добавляете ООП в уже существующий код — ваши руки оказываются «связанными».

                                                                  Что значит "разумеется"? Inkscape уж 15+ лет существует… пару раз что угодно переписать можно было, если бы была насущная необходимость.
                                                                  Да и вообще когда есть понимание, как надо переделать и зачем, руки ничто не связывает.

                                                              –2
                                                              А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.
                                                              «Все врут календари» (С) :)))
                                                +1
                                                Как видите, тут нет никакого требования чтобы сообщения были объектами.

                                                Я, конечно, дико извиняюсь, но это следует из первого пункта тупо посредством формальной логики. Сообщение — это что-то, что можно пощупать внутри языка (как минимум, его можно создать, отправить или получить). Значит, это объект по п. 1.


                                                Третий пункт я, впрочем, понять не могу, но это так, к слову.

                                                  0
                                                  С одной стороны да, но как тогда к нему применить второй пункт?
                                                    +1

                                                    А в чём вопрос?


                                                    Можно отправить сообщение сообщению. Можно отправить сообщение сообщению сообщению. И так индуктивно, по крайней мере, до первого счётного ординала.

                                                      +1
                                                      И так индуктивно

                                                      Ok. Для обфускации очень подойдет :)
                                                        0
                                                        Послать — не проблема, просто создал и оно само куда-то побежало.
                                                        А вот как принять, если объектам запрещено между собой взаимодействовать?
                                                          0

                                                          Почему запрещено? Кем запрещено?


                                                          Не, наверное, можно построить формальную иерархию уровней объектов, получится что-то вроде ω различных сортов классов с более-менее очевидным formation rule для того, какие отправки сообщений кому валидны, но это, наверное, перебор. Основополагатели ООП не были матлогиками, насколько я знаю.

                                                            0

                                                            В ответ на приход запрещенного сообщения геренировать ошибку.

                                                        0

                                                        Зависит от степени вашего формализма )))
                                                        Можно понимать первый пункт так:
                                                        Программа состоит из объектов, нет никакого кода, исполняющегося вне объектов.


                                                        При этом что там внутри объектов происходит (п.3) и как они коммуницируют (п.2) — темы отдельные и формально не требуют ни наличия объектов внутри own memory объекта, ни использования объектов для передачи сообщений.

                                        0
                                        Что плохого в том, чтобы из каждого ящика с инструментами взять только самые удобные

                                        Ничего плохого, но ни слова про удобство в комментарии на который вы отвечаете не было, и далеко не факт что именно удобство стало причиной такого упрощения.
                                          0
                                          Не удобства точно. Простота понимания и реализации исключительно.
                                            +1
                                            не думаю что дело в этом. Вряд ли Smalltalk, реализующий кошерный ООП и написанный в 80-х был сильно непонятным или сложно реализуемым. Проблема, полагаю, скорее в самом процессе разработки — код, в котором свойства объектов заранее неизвестны, сложно поддается как чтению, так и статическому анализу.
                                              +1
                                              Вряд ли Smalltalk, реализующий кошерный ООП и написанный в 80-х был сильно непонятным или сложно реализуемым.
                                              Не «вряд ли», а «совершенно точно». Вы не могли, условно говоря, взять программу на FORTRAN и записать её на SmallTalk. Вся работа с плавучкой — через посылку сообщений, встроенным у него только int был. И эффективность у него была, мягко говоря, не очень.

                                              А вот Turbo Pascal 5.5 — отлично работал на XT с 512K, а если очень надо было, то и на PC с 256K (среда не запускалась, но можно было использовать какой-нибудь другой редактор… Turbo Pascal 3.0, к примеру).

                                              А сейчас компьютеры выросли, но мы работаем с «замечательным» гибридами: языками, которые выразительность взяли от Turbo Pascal 5.5, а эффективность — от Smalltalk'а. Потрясающая комбинация.
                                              0
                                              Привычка же )
                                              Кей писал что ST и его парадигма стали «чем-то таким чем нужно учиться», у Девида Веста ещё популярный доклад на эту тему где он маркетинг винит в уничтожении хороших идей.
                                          0
                                          промазал)
                                            +2
                                            изначальной концепции, когда объектам посылаются сообщения

                                            а сигналы и слоты из Qt подходят под «изначальную концепцию»?

                                            P.S. Скорее всего нет никакой абсолютной изначальной концепции…
                                            Хорошо знать разные подходы и применять лучшие практики для конкретного класса задач.
                                            И понимать, что все развивается, меняется, переосмысливается.
                                            Экспериментам и ошибкам тоже есть место…
                                              0

                                              Кутешные сигналы и слоты — это реализация паттерна publish/subscribe. И реализовывать обмен сообщениями двух конкретных наперёд известных объектов с их помощью считается моветоном.

                                                0

                                                С каких пор это моветон? Там все API на них, от таймеров до UI. Тот же QML, кстати, весь по сути статический (определен заранее), но все на сигналах. Какое-то очень категоричное суждение получилось...

                                                  0

                                                  Когда вы пишете код класса QTimer, вы не знаете, какие клиенты и как им будут пользоваться, и сколько их вообще будет. Там pubsub оправдан (как для почти любого библиотечного класса). Если же вы пишете конечный код с бизнес-логикой, для которого в момент написания известно, кто с кем как взаимодействует, то сигналы и слоты там не нужны (и именно поэтому я написал про «наперёд известных»).


                                                  А QML вообще отдельная история. Сигналы там — скорее костыль вокруг выразительных способностей языка (в момент компиляции неизвестно, что там в QML будет и какие сигналы/методы будут доступны). Поэтому, кстати, соединиться новым синтаксисом с сигналами QML-объектов у вас не получится, только старые-добрые строки, генерируемые макросами SIGNAL и SLOT.

                                                    0
                                                    если же вы пишете конечный код с бизнес-логикой, для которого в момент написания известно, кто с кем как взаимодействует, то сигналы и слоты там не нужны (и именно поэтому я написал про «наперёд известных»).

                                                    ну во-первых, API Qt довольно-таки сильно привязан к сигналам/слотам. Бизнес-логика всё-таки имеет свойство взаимодействовать с GUI/БД/сетью/т.д. Во-вторых, абстрактные «наперед известные» объекты могут жить в разных потоках. Но соглашусь, что пересылать большой поток данных через сигналы/слоты может быть неуместно
                                                      0
                                                      ну во-первых, API Qt довольно-таки сильно привязан к сигналам/слотам.

                                                      Ну ещё бы, какой-нибудь dataChanged для модельки в MVC — самое оно. Вы не знаете, какие у вас вьюшки будут, сколько их, и так далее. Или там вообще, может, одна модель в другую прокси-модель завёрнута будет.


                                                      А вот QNetworkReply::finished — уже унылее, кстати. Я поэтому накорябал обёрточку, которая в QFuture всё заворачивает. Гораздо удобнее и лучше стало, коммиты с переносом удаляют много строк, а добавляют мало, и некоторые члены классов больше не нужны, и так далее.


                                                      Бизнес-логика всё-таки имеет свойство взаимодействовать с GUI/БД/сетью/т.д.

                                                      Про сеть я выше написал.


                                                      А для работы с БД у меня тоже QFuture-based API, где надо. С сигналами и слотами состояние размазывается по коду, получается месиво.


                                                      Во-вторых, абстрактные «наперед известные» объекты могут жить в разных потоках.

                                                      Паттерн publish/subscribe про это ничего не знает, это переиспользование деталей реализации сигналов/слотов в кутях для решения другой задачи. Так-то можно и событие послать объекту.

                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                +1
                                                Насколько мне известно, в Objective-C можно отправить любое сообщение любому объекту, даже то, на которое он не знает как отвечать, в C++ — можно вызвать только те методы, которые публичные.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    Позднее связывание, полагаю. Вообще похоже, что для Алана Кея ООП немыслим без динамической типизации.
                                                      0

                                                      В D можно принимать любые выводимые на этапе компиляции сообщения: https://tour.dlang.org/tour/en/gems/opdispatch-opapply

                                                        0

                                                        Смотря что считать динамической типизацией. Я как-то ради фана сделал что-то вроде true OOP на PHP, что вроде легко переводилось на Java/C#. Типизации вполне статическая, просто есть метод handleMessage(AbstractMessage message) у каждого класса.

                                                          0

                                                          А в этой реализации можно было послать сообщение сообщению? :)

                                                            0

                                                            Можно было :) handleMessage был методом Object от которого наследовались все объекты включая Message

                                                        0
                                                        Кроме позднего связывания хотел бы добавить о возможности расширения классов «снаружи», в пользовательском коде, без наследования, чтобы обраватывать новые, ранее неизвестные сообщения.
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                            0

                                                            Абсолютно правильно, как пример:


                                                            @interface Counter
                                                            -(NSInteger) increment;
                                                            @end
                                                            // Добавляем новый функционал через категорию -
                                                            // элемент языка, который служит для расширения
                                                            // функциональности класса.
                                                            @interface Counter (CountByTen)
                                                            -(NSInteger) incrementByTen;
                                                            @end
                                                            
                                                            // И где то в коде.
                                                            Counter *counter = [[Counter alloc] init];
                                                            [counter incrementByTen];

                                                            Если вас сильно заинтересовал язык, посмотрите доку Яббл о нем.

                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                0
                                                                Скорость не нужна от слова совсем?
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    0

                                                                    Интерпретируемые языки взлетели когда железо ещё дорогое было. Из 4-х первых языков высокого уровня, как-то доживших до наших дней, Lisp и BASIC — интерпретируемые, Fortran и Cobol — компилируемые.

                                                                      +1
                                                                      BASIC — изначально учебный язык для коротеньких программ, и после него хорошо учить тот же ForTran.
                                                                      Хотя, начиная с 1975 года, он стал основным языком для персоналок, где он входил в комплект поставки по умолчанию. То есть да, можно признать, что действительно взлетел.
                                                                      image

                                                                      LISP — тогда требовал специальных LISP-машин более чем вдвое превосходивших по цене тогдашнее типичное топовое железо: топовый компьютер в 1975 году стоил $20 тысяч (самый дешёвый стоил $439), а LISP-машина в те годы стоила от $50 тысяч. И потому имел узкое нишевое применение — там, где были эти LISP-машины (в 1975 году их было два с половиной десятка, и семь тысяч на 1988 год).
                                                                      Хотя, конечно язык — признаю взлетел, но до современных компьютеров, был в очень узкой нише = в золотой клетке.
                                                                      image
                                                                        0
                                                                        BASIC — изначально учебный язык для коротеньких программ
                                                                        Что назвать «коротенькой»: в сетке можно, нпр., найти игру Star Trek на BASIC-е для PDP-11. Она не очень коротенькая ;)
                                                                  0

                                                                  А зачем это вообще может понадобиться, методы всякие к имеющемуся типу добавлять?

                                                                    0
                                                                    Для имитации «методов, висящих в воздухе» в стиле CLOS.

                                                                    А для чего это может понадобиться — ну так можно придумать массу примеров.

                                                                    Ну например жил-был у вас GUI, рассчитанный на мышь. И захотели вы сделать GUI для телефона. Во многих случаях вы можете просто обрабатывать touch как клик мышкой. Но в некоторых классах (уже существующих!) — хочется другого поведения.

                                                                    В Objective C — это делается вот через расширения. Ну а в C++/Java — через фабрики-фабрик-фабрик с соответствующей потерей эффективности.
                                                                      0

                                                                      Ну так берёте и меняете эти классы, в чём вопрос? Вам же всё равно гуи-фреймворк менять придётся, чтобы там тач-эвенты правильно создавались где надо.

                                                                        0
                                                                        Что значит «берёте и меняете»? Если у вас программа большая, то так просто чужие классы менять не дадут. А если это чужая, готовая, библиотека — то и вообще никак не дадут.
                                                                          0

                                                                          А поддержку тач-событий вот вы так просто взяли и запилили в этом случае?


                                                                          Какой-то нереалистичный пример.

                                                                            0
                                                                            А поддержку тач-событий вот вы так просто взяли и запилили в этом случае?
                                                                            Для большинства контролов достаточно замапить их в сообщения мыши, специально обрабатывать нужно только где-нибудь в Edit Box'е.

                                                                            Какой-то нереалистичный пример.
                                                                            Вообще-то это вполне себе пример «взятый из жизни»… другое дело что со временем поддержка iOS становится всё более важной (сегодня она, пожалуй, важнее, чем поддержка MacOS) и библиотеки начинают поддерживать тач нативно.

                                                                            Но лет десять назад — такое вполне себе делали.
                                                                              0

                                                                              Все известные мне гуи-фреймворки позволяют навешивать event filter'ы, чего в данном случае более чем достаточно.

                                                                      0

                                                                      Допустим, есть какая-то сторонняя библиотека, которую уж очень нравится и хочется использовать. И во всем нашем коде используется типовой код использующий класс из библиотеки, значит выносим в отдельный метод. В той же Java этот метод будет жить в классе-хелпере (не бейте ногами с жавой не сильно знаком). А в обжективе можно расширить класс нужной нам типовой (для нас) функциональностью.

                                                                        0

                                                                        Я, наверное, просто никогда не понимал ООП, но чем плохо просто вынести это в отдельный метод, как вы и написали?

                                                                          0
                                                                          Допустим, есть какая-то сторонняя библиотека, которую уж очень нравится и хочется использовать. И во всем нашем коде используется типовой код использующий класс из библиотеки, значит выносим в отдельный метод. В той же Java этот метод будет жить в классе-хелпере (не бейте ногами с жавой не сильно знаком). А в обжективе можно расширить класс нужной нам типовой (для нас) функциональностью.

                                                                          Расширять своей функциональностью класс из сторонней библиотеки? Странные… кхм… вкусы у вас.

                                                                          Почему бы не сделать удобный интерфейс объявляющий нужную вам функциональность, и уже в его реализации использовать стороннюю библиотеку, или хотя бы просто декоратором функциональность расширять?
                                                                            0

                                                                            Никто не говорит о том, что я не делаю подобное через интерфейс.
                                                                            Но объясните, пожалуйста, зачем мне декораторы, если я могу заимплементить протокол (интерфейс в терминах obj-c) уже существующему библиотечному классу? И в этой имплементации пользовать базовый функционал класса.


                                                                            Так что, о вкусах не спорят. =)

                                                                        0

                                                                        final class есть и в интепретируемых )

                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                            0
                                                            Концепция именно в этой формулировке крайне тяжела для статического анализа и борьбы со сложностью.

                                                            Что хорошо показали Руби и Питон. А также ЯваСкрипт, но там все иначе и ппоэтому плохой пример. В этих языках очень много лапши кода, даже во взрослых библиотеках и фреймворках. Более того, сами философии языков борятся с теми, кто пытается бороться с такой лапшой.

                                                            С другой стороны, этот подход хорош на ограниченном множестве сущностей. Как пример, в ОРМах или фасадах модулей.
                                                              –2
                                                              А где доказательство, что изначальная концепция лучше «упрощенной»? (м.б., нпр., ЯП, отвечающие изначальной концепции, пользуются большим спросом и т.д.)
                                                                0
                                                                изначальная концепция лучше «упрощенной»

                                                                Я такого не утверждал (ровно как и не стал бы утверждать обратного).

                                                                  +4
                                                                  (м.б., нпр., ЯП, отвечающие изначальной концепции, пользуются большим спросом и т.д.)
                                                                  Языки, пользующиеся большим спросом — это не самые лучшие языки, а языки «попавшие в струю», извините.

                                                                  C/C++ — взлетел вместе с Unix, Javascript — это Web, Java — это вообще в чистом виде «каша из топора», когда миллиарды долларов, вбуханных в поделку, которая была хуже альтернатив по всем параметрам, привели к тому, что после многих лет развития — она превратилась-таки в что-то, чем реально можно пользоваться…

                                                                  Да собственно если бы хорошие языки были популярными, то C и C++ никогда бы не стали языками #2 и #3: они же ужасны!
                                                                +2
                                                                Класс это — несколько свойств и функций объединенных под одним неймспейсом. Класс может скрывать от внешнего мира свойства и методы, может наследовать поведение от других классов, может переопределять поведение у наследуемых классов. Вот и весь ваш ООП. Зачем делать из этого фетиш и десятилетиями обсасывать это, вообще не понимаю.
                                                                  +2
                                                                  Вот такое понимание класса потом и приводит к GodObject'ам, спагетти коду и сотне разных антипаттернов.
                                                                  Класс это не скопище функций и свойств, это таки логически обособленная единица кода и «обсасывания» временами вполне обоснованными могут быть.
                                                                  Если вы обернёте весь код в класс MyProgram, это будет не ООП, а вполне себе императивщина
                                                                    –1
                                                                    Умение разделять код, с классами и представлением о них, никаким образом не связано. С успехом можно разделять код на функции, всё зависит от повара.
                                                                      0
                                                                      Шта? Либо я чего-то не понимаю, либо где-то тут бред.
                                                                      Умение строить дом никак не связанно с представлением о стенах, умение писать текст никак не связанно с тем что я понимаю под фразами...

                                                                      Типа да, без разницы будете вы выделять в коде классы и интерфейсы, типы и монады, структуры и трейты либо что-то ещё, основная проблема в понимании что в какой класс/тип/трейт выделить и какие уровни абстракции использовать.
                                                                      При восприятии классов как обёрток для методов и свойств это, имхо, сложновато будет сделать.

                                                                      Вся эта чепуха придумана для разумного управления сложностью, и если нагромождения классов и наследований делают код нечитаемым, есть смысл обсуждать и искать решения десятилетиями, не?
                                                                        –1
                                                                        Ну не просто обертка, а сущность состоящая из свойств и методов, с определенным поведением. Каким местом это к разделению кода непонятно, GO/Rust классов нет совсем, и ничего.

                                                                        А так конечно, видите то чего нет, тоже уметь надо.
                                                                    0
                                                                    О, этот дивный период, когда все мудрости мира у тебя на ладони и вся суета вокруг кажется такой бессмысленной, ведь истина, вот она — проста и интуитивно понятна. Люди до сих пор до нее на додумались и ведут ненужные споры.
                                                                    Какой там язык сейчас рулит, кстати?
                                                                      0
                                                                      Лучше так, чем напридумывать абстракций и спорить до инфаркта, чья лучше. Проще надо быть.

                                                                      Язык нужно выбирать в зависимости от задач/платформы. Разве что JS рулит везде, в основном благодаря быдлокодерам.

                                                                      P.S. Сам я конечно быдлокодер, прошу строго не судить.
                                                                    +4
                                                                    Что в итоге оказалось мифом, а что реальностью? Как ещё одно мнение о том, что такое (или нет) ООП — понятно.

                                                                    Но тема не раскрыта, как мне кажется.
                                                                      0
                                                                      Нпр., миф Серебряной пули:
                                                                      правы все: [...] и противники, когда негодуют на возведение ООП в статус серебряной пули, абсолютного оружия.

                                                                      Это широко известный миф:
                                                                      Фредерик Брукс указывает, что наиболее сложной частью создания программного обеспечения является «…спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…»[22].


                                                                      Еще: Экзистенциальный Вопрос „Что Есть Объект?“»
                                                                      + проблемы модельного подхода…
                                                                        +1
                                                                        Далее по книге Фредерик Б. пишет о том что под термином ООП скрывается 2 по сути не похожих друг на друга подхода. Один на классах, а второй на компонентах.
                                                                        Если открыть википедию, то увидите что там уже 3 типа ООП методологии: классы, компоненты и прототипы.
                                                                        Беда в том что разум 99% программистов ограничен только классами. Они в упор не хотят замечать существование альтернативных ООП концепций.

                                                                        При этом побеждают на рынке те платформы, которые научились готовить ООП не только на классах, но и грамотно применять компонентные ООП подходы: Angular vs React, Drupal vs WordPress.
                                                                      –2

                                                                      В концепции ООП прямоугольник сам должен уметь себя двигать (метод Move(area, dx, dy)) или его должен кто-то уметь двигать (класс Area с методом MoveRect(rect, dx, dy) / Move'T(T, dx, dy))?


                                                                      Вот когда есть множество вариантов использования и появляются споры. Причина — следствие...

                                                                        +1
                                                                        А есть парадигмы, в которых любую задачу предметной области можно решить ровно одним способом?
                                                                          0

                                                                          Если бы для решения одной задачи был бы только один способ, жить было бы не интересно!
                                                                          А как правильно будет для данного примера? Интересно услышать мнение...

                                                                            +2
                                                                            А как удобно — так и правильно. Что удобно, а что нет, определяется в контексте всей архитектуры в целом. Сферовакуумный «hellow world» можно делать как угодно, его цель — не решить прикладную задачу, а продемонстрировать, что «вот так тоже можно».
                                                                              0
                                                                              Полностью согласен, но ИМХО нужно уточнить, что под удобством понимаем стиль опытного кодера, а не халтуру неуспевающего школьника.
                                                                                0

                                                                                Да, профессионал всегда сможет аргументировать способ решения задачи!

                                                                                  0
                                                                                  Да, проблема только в том, что другой профессионал может с ним не согласиться ;)
                                                                                    0

                                                                                    Как это? Аргументы же есть! )

                                                                                      +1
                                                                                      Я иногда себе могу контраргументов накидать кучу, что уж про остальных говорить
                                                                                        –1

                                                                                        Это очень хорошо! Значит, меняйте решение, если конечно, архитектура, построенная на выбранных с помощью неких аргументов и "принципах" ООП, позволит Вам это сделать…

                                                                                    0

                                                                                    Даже очевидно плохой и неправильный — на то он и профессионал :D

                                                                                    +1

                                                                                    Вот тут возникает типичная проблема: стиль школьника часто позволяет быстрее сдать выполненную работу. Причем сильно быстрее. Результат будет хреновым, но это заметят далеко не сразу, иногда через годы. Отсюда — поиски технологий (в т.ч. языков), позволяющие опытному кодеру не жертвовать скоростью кодинга ради качества.

                                                                                      0
                                                                                      Вот тут возникает типичная проблема: стиль школьника часто позволяет быстрее сдать выполненную работу. Причем сильно быстрее. Результат будет хреновым, но это заметят далеко не сразу, иногда через годы.
                                                                                      Чаще препод замечает сразу — и не только плохой стиль, вернее его отсутствие, но и баги. И не принимает такую «работу» ;)

                                                                                      ИМХО байки о супергениальных школьниках — во многом еще один миф. Про поиски технологий согласен.
                                                                                        0

                                                                                        А при чем здесь препод? Я как препод могу заявить, что не обращаю внимания на стиль. Студенту итак сложно, а если его грузить стилем программирования, он вообще ничего не сделает, плюнет и пойдет в армию! )

                                                                                          0
                                                                                          ИМХО стиль — м.б. самое важное, но не буду спорить: у каждого своя метода.
                                                                                            0

                                                                                            Мы поступали не так. Мы давали на решение задачи много времени, при этом в процесс сдачи включали code review преподавателем. Задача считалась зачтенной, когда студент объяснял причины выбора того или иного способа написания. К самому способу мы не придирались, просто спрашивали. Но порождаемые неудачным написанием опасные баги (вроде утечек памяти) велели устранять.

                                                                                              0
                                                                                              Интересно: а если студент пишет комментарий «zapisat dannie v jurnal» и соответственно дает имена типа zapisvjurnal, такое зачтется? — Ведь не переключать регистр «клавы» и не вспоминать английские слова быстрее, если есть проблема с языком.
                                                                                                0

                                                                                                Думаю, любой преподаватель укажет на это, но на зачет влиять не будет. В случае какой-нибудь школы программирования, конечно подобное недопустимо, как и любые другие общеизвестные правила написания кода.

                                                                                                  0
                                                                                                  ИМХО если у студента программирование профильный предмет, то он должен соблюдать общие правила, но если речь о гуманитарии или о школьнике, то должен понимать, что такой код — неуважение к читателю, прежде всего к преподавателю. Думаю преподавателю нужно экономить собственное рабочее время, а то на всех студентов не хватит. Лучше пусть меньше получат фактических знаний, чем не привыкнут к нормальному оформлению. Но это ИМХО — у меня небольшой опыт преподавания, правда в солидных местах — МГТУ, МГУ.
                                                                                                    0

                                                                                                    Речь о среднестатистическом студенте, а не о специальности АСУ в МГУ… Вы в праве иметь собственный подход к преподаванию,, конечно же. Практика покащывает, что студент, который хочет программировать либо спросит, либо разберется, либо к нему другие пожелания преподавателя, в тч те, о которых, говорите Вы.

                                                                                                      0
                                                                                                      ИМХО тут серьезная проблема. В Инете и, в частности, на Хабре много жалоб на понижение качества образования. При этом снижается осознание роли образования — некоторые школьники считают, что сразу после окончания школы смогут писать код за хорошие деньги. И при этом мои знакомые в вузах жалуются, что возрастает давление на преподавателей: стоит не поставить одному студенту зачет — целая делегация отправляется в деканат.
                                                                                                        +1
                                                                                                        понижение качества образования… стоит не поставить одному студенту зачет — целая делегация отправляется в деканат

                                                                                                        image
                                                                                                        Замкнутый круг ещё более понижающий качество образования!
                                                                                                        image
                                                                                                        некоторые школьники считают, что сразу после окончания школы смогут писать код за хорошие деньги

                                                                                                        Даже на Хабре, полно статей «нах мне математика?!» и «нах мне ВУЗ?!».
                                                                                                          0
                                                                                                          Даже на Хабре, полно статей «нах мне математика?!» и «нах мне ВУЗ?!».
                                                                                                          Хороший был бы аргумент, только это мнение исходит далеко не только от школьников, но и в большей степени от тех, кто в этом самом ВУЗе изучал эту самую математику, и пришёл к выводу, что в работе ему всё это в лучшем случае бесполезно.
                                                                                                            –1
                                                                                                            кто в этом самом ВУЗе изучал эту самую математику, и пришёл к выводу, что в работе ему всё это в лучшем случае бесполезно
                                                                                                            При этом не все укзывают какая у них работа. Нпр., около моего дома продуктовый магазин, и там одна девушка с высшим образованием овощами торгует…
                                                                                                              +1

                                                                                                              Обычно статьи всё же «нах мне, программисту, математика?!» и «нах мне, программисту, ВУЗ?!»

                                                                                                                0
                                                                                                                Ok. Естественное желание многих школьников сразу по окончании школы получать хорошую ЗП, а не тратить 5 лет на вуз. — Вот он и делится с сообществом своими мечтами.

                                                                                                                Кто окончил вуз, но условно говоря торгует овощами — не обязательно за прилавком, а м.б. топ-менеджер крупной фирмы и через него каждый день проходят сделки на много тонн овощей и фруктов, видит, что кроме 4 арифметических действий никакая математика ему не нужна.

                                                                                                                Но не все собираются всю жизнь торговать овощами и не все смогут найти работу топ-менеджера крупной фирмы. — Как повезет, кому «не повезет» — тому м.б. будет нужна математика :)
                                                                                                                  +1
                                                                                                                  топ-менеджер крупной фирмы и через него каждый день проходят сделки на много тонн овощей и фруктов, видит, что кроме 4 арифметических действий никакая математика ему не нужна

                                                                                                                  third112, если он реально топ, а не свадебный генерал, который ничего не решает, то он имеет дело помимо прочего и с реальными финансами, с весьма специфическими формулами:
                                                                                                                  image
                                                                                                                  (на картинке не просто примитивный дебет-кредит на уровне ПТУ, а продвинутая бухгалтерия западного образца от Chartered Institute of Management Accountants)

                                                                                                                  Погуглите, что такое Corporate Finance.
                                                                                                                    –1
                                                                                                                    Бывает и такое, но я чаще видел «примитивный дебет-кредит на уровне ПТУ».
                                                                                    0
                                                                                    Присоединяюсь, интересно услышать мнение.

                                                                                    ИМХО (учитывая количество вводных данных): кто-то должен уметь двигать прямоугольник. %)
                                                                                  –1
                                                                                  Если у нас только прямоугольники — то всё равно. А если 100500 разных объектов — то разумно определить что каждый сам лучше знает как себя двигать.
                                                                                  Ну и…
                                                                                  Area.Move(object, dx, dy) => { object.Move(dx, dy) }

                                                                                  (эээ… на каком это я языке написал? ну надеюсь поняли что хотел сказать)
                                                                                  +2

                                                                                  Более важно, на мой взгляд, вот что. Любая сущность, которую вводят в языках программирования, обладает определенными математическими свойствами. Эти свойства, если они удобны, позволяют проверять корректность кода и/или эффективно оптимизировать его при компиляции. Напротив, неудобные свойства приводят к путанице и либо провоцируют ошибки, либо заставляют перегружать код лишней писаниной, чтобы из имеющихся свойств построить желаемые.


                                                                                  В ООП не очень понятно, чем является класс. Это не множество. Это и не класс из математики. Наследование классов не дает ни надмножество, ни подмножество. Поэтому, когда с помощью ООП пытаются выразить типичные для множеств соотношения вроде "окружность — частный случай фигуры на экране", начинают требоваться особые и часто неинтуитивные приемы работы с ООП (часть из них известна как "пэттерны", часть — негласные, но всеми используемые приемы).


                                                                                  Поэтому важно не то, есть в названии языка слово "объектно-ориентированный" или нет, а то, построен ли язык вокруг какой-то удобной аксиоматики. Когда язык строят последовательным добавлением "а вот еще вот эту фичу", получаются внутренние противоречия и парадоксы. Совершенно понятно желание многих людей иметь язык программирования, свободный от парадоксального поведения.

                                                                                    0
                                                                                    Любая сущность, которую вводят в языках программирования, обладает определенными математическими свойствами.
                                                                                    Сможете назвать мат. аналог понятию «файл»? Когда-то участвовал в обсуждении этого вопроса на кафедре высшей математики одного из знаменитых московских вузов — в том обсуждении никто не смог назвать точного мат. аналога. Т.о. ИМХО не все базовые понятия CS являются мат. понятиями. Хотя математика и CS имеют значительные пересечения, но, даже, природа этих наук разная: CS экспериментальная наука, а математика нет.
                                                                                      +3

                                                                                      Ну, содержимое файла — конечное упорядоченное множество пар (номер, байт), операции над содержимым двух файлов, дописывание в файл соответствуют как минимум моноиду (ассоциативность есть, единичный элемент — пустой файл — есть). Имена файлов — граф, дерево. Точного названия для такой штуки в математике скорее всего нет, но многие аксиомы для свойств можно записать сразу.

                                                                                        0
                                                                                        Точного названия для такой штуки в математике скорее всего нет
                                                                                        И в том обсуждении, которое вспомнил, все сошлись на том, что «точного названия в математике нет», поэтому в CS есть нематематическая специфика. Без мат. методов CS не обойтись, но решить все задачи CS только мат. подходом не получится.
                                                                                          +1

                                                                                          Скорее не так: "точного названия в математике пока не придумали". Ничто не мешает написать строгую аксиоматическую теорию файлов. Точно так же, как давным-давно была написана строгая аксиоматическая теория взамен рисования геометрических фигур палочкой на песке. Соответствующий математический объект будет называться "файл".

                                                                                            0
                                                                                            Ничто не мешает написать строгую аксиоматическую теорию файлов.
                                                                                            Но почему-то никто не пробует написать такую теорию, а файлы используют все ;)
                                                                                              0
                                                                                              Почему не пробуют? Разработчики файловых систем только этим и занимаются :).
                                                                                                0
                                                                                                И где такая теория? где мат.аналог файла? Нпр., есть матричная алгебра, но о файловой алгебре что-то не слышно.
                                                                                                  +2
                                                                                                  Ок, это не обобщённая теория «любого файла», это описание того, что такое файл, в данной конкретной файловой системе, и какие операции с ним можно или нельзя производить. Каждый из этих стандартов, конечно, хотел бы быть самыми главными, но «файла с научной точки зрения» действительно пока не сочинили :).

                                                                                                  P.S.: Вспоминая старые советские учебники по информатике припоминаю что-то такое, думаю, можно найти ГОСТ с описанием сущности «файл в информационной системе».
                                                                                                    0
                                                                                                    Ок, более того, известно много общих алгоритмов работы с файлами, не завязанных на конкретную файловую систему — нпр., внешние сортировки.
                                                                                          0

                                                                                          Конечность, строго говоря, не обязательна: \ dev\null тому пример. И вы правильно определили основные структуры, присущие файлу, как математическому объекту.

                                                                                            0

                                                                                            Надо ещё добавить временной аспект, и тут вылезут какие-нибудь сложности. И, кстати, не граф и даже не DAG, есть же хардлинки. Можно даже цикл сделать.


                                                                                            Но да, аксиоматизировать можно. Просто непонятно, какую теорию из этого можно будет построить и какие нетривиальные результаты она даст.

                                                                                              0
                                                                                              не то что можно…
                                                                                              Вот на днях ставил убунту — так там на дистрибутиве папка ubuntu есть линк на корень диска. И в неё можно углубляться бесконечно.
                                                                                            0

                                                                                            Таки "в основном — чёткие правила, но иногда — исключения" всё равно лучше, чем "пиши как хочешь; есть, конечно, пара правил, но и их нужно воспринимать скорее как правила хорошего тона, а не жёсткий канон".

                                                                                              0

                                                                                              Это называется проблема поиска денотационной семантики. Работа в этом направлении идёт и далека от завершения. Для многих это жуть жуткая и муть мутная, каждый день не нужная. Но для тех кто пишет компиляторы и верификаторы это крутой инструмент.
                                                                                              А файл (POSIX) можно отождествить с анаморфизмом, порождающим свободный моноид, его обработчики — с гиломорфизмами. Файловая система — дерево, или более общий граф, если она реляционная и т.п. Мы используем эти понятия, не зная, что "говорим прозой".


                                                                                              И хотел бы добавить, современная математика огромна. Не торопитесь судить о ней в терминах "никакая математика не определит"… Например, о трех табуретках: теория устойчивости, даже линейная удовлетворительно отличит одно применение от другого.

                                                                                                0
                                                                                                И хотел бы добавить, современная математика огромна. Не торопитесь судить о ней в терминах «никакая математика не определит»…
                                                                                                Cовершенно серьезно: это сложный вопрос философии и методологии науки. Ok: математика огромна — это факт. Но этот факт не противоречит факту, о котором сказал выше, что
                                                                                                природа этих наук разная: CS экспериментальная наука, а математика нет.
                                                                                                см.:Newell, Allen; Simon, H. A. (1976), «Computer Science as Empirical Inquiry: Symbols and Search» (1975 ACM Turing Award Lecture), Communications of the ACM, 19
                                                                                                Можно сделать мат. модель файла, но мы столкнемся с ограничениями моделирования, о которых в статье.
                                                                                                  0

                                                                                                  Вот именно. Что характерно, все чаще именно в документации к прикладным библиотекам появляется отдельная главка с денотационной семантикой ее вызовов. И у тех, у кого она есть, обычно все работает круто и продуманно.

                                                                                                  0
                                                                                                  конечно же есть абсолютно точное математическое (из мат логики) — «файл» это «кортеж».
                                                                                                  0

                                                                                                  Кстати, насчет паттернов. Складывается впечатление, что ООП — есть суть, набор паттернов. Т.е. некие согласованные правила написания кода. Думаю, паттерны и были порождены тем самым множеством вариантов использования в ООП. И люди, пытаются упростить себе жизнь.


                                                                                                  Чем больше я писал код в ООП, тем чаще выдумывал паттерны. Честно говоря, устал — надоело! Слез с ООП в итоге в пользу декларативных подходов и простоты Go.

                                                                                                    +1

                                                                                                    Аналогично, только ушел на Rust и часто пользуюсь функциональным подходом в нем. Rust — потому что я на C++ писал много низкоуровневых оптимизаций, со ссылками на стек и т.д., чтобы без счета ссылок и без сборки мусора, а именно на compile-time, и на Rust это как раз очень хорошо ложится. Go смотрел, хороший язык, но совсем не для моих задач.

                                                                                                      0

                                                                                                      Ну идея Go как раз в том и заключается, что хватит выдумывать паттерны! Пишем все одинаково и понимаем друг друга!

                                                                                                        0

                                                                                                        В Rust тоже. Только там оставили управление памятью от C/C++, спрятав его под синтаксический сахар, и притащили типизацию в духе Haskell.

                                                                                                    0

                                                                                                    Не, ну почему.


                                                                                                    В ООП не очень понятно, чем является класс. Это не множество.

                                                                                                    Это тип в STLC с некоторыми расширениями (записи там, сабтайпинг).


                                                                                                    Наследование классов не дает ни надмножество, ни подмножество.

                                                                                                    Почему, даёт подмножество, как раз в смысле сабтайпинга.


                                                                                                    начинают требоваться особые и часто неинтуитивные приемы работы с ООП

                                                                                                    Они начинают требоваться в момент мутабельности (ИМХО), когда у вас накладываются дополнительные ограничения на ковариантность и контравариантность семантики методов. И да, получаются вопросы о том, кто должен от кого наследоваться между квадратом и прямоугольником, и что для каждого из них в рамках этой иерархии должен делать метод setWidth.

                                                                                                    0
                                                                                                    В конце прошлого века всемирно известные люди Билл Гейтс, Филипп Кан, Бьёрн Страуструп, Никлаус Вирт и др., не желая того, заложили бомбу под ООП, слишком восторженно его пропагандируя.
                                                                                                    Не мог бы автор статьи рассказать, где, когда и как именно Вирт пропагандировал ООП? Ни в одном из языков, созданных Виртом, нет классов, объектов и наследования. Вирт (и позаимствовавший идеи Вирта язык Go) пропогандирует компонентный подход (альтернативный ООП, построенному на наследовании), являющийся очень простым расширением классического процедурного програмирования.
                                                                                                      0
                                                                                                      ЯП Оберон. ИМХО компонентно-ориентированное программирование это мод ООП.
                                                                                                        0

                                                                                                        Скорее наоборот, ООП — мод компонентно-ориентированного программирования...

                                                                                                          0
                                                                                                          Ok. Можно сказать и так.
                                                                                                          0
                                                                                                          Oberon не имеет классов, объектов и наследования. Это ООП?
                                                                                                          JavaScript — не имеет классов и инкапсуляции (впрочем, недавно в JS добавили пародию
                                                                                                          на классы, но это только синтаксический сахар). Это ООП?
                                                                                                          Полиморфизм? Так он прекрасно реализуется в любом языке, поддерживающем ссылки на подпрограммы — безо всякого ООП.
                                                                                                          Так что такое ООП? И как может быть ООП в языке, не имеющем объектов? Может быть, стоит дать определение ООП — прежде чем смешивать мух и котлет?
                                                                                                            0
                                                                                                            Oberon не имеет классов, объектов и наследования. Это ООП?
                                                                                                            Сужу по Вики (я только читал про Oberon, но ничего на нем не писал):
                                                                                                            Заголовок спойлера
                                                                                                            Инкапсуляция поддерживается исключительно на уровне модуля — все типы, объявленные внутри модуля, друг для друга абсолютно прозрачны. Из других модулей доступно то, что объявлено при определении как экспортируемое.

                                                                                                            Полиморфизм обеспечивается за счёт механизма методов (и процедурные поля в Обероне, и методы в Обероне-2 ведут себя как виртуальные, в терминологии большинства гибридных объектно-ориентированных языков), а также расширенной конструкцией WITH, позволяющей выполнять различные группы операторов в зависимости от того, к какому из расширенных типов относится её аргумент.

                                                                                                            В языке отсутствует специальный механизм конструкторов. Рекомендуемым методом создания и инициализации объектов является описание порождающих модулей и процедур (в традиционной терминологии ООП — factory).

                                                                                                            Программа в такой технологии представляет собой набор относительно самостоятельных компонентов (в данном случае — модулей), имеющих скрытую от внешнего мира внутреннюю структуру и чётко определённый интерфейс. Модули могут загружаться и выгружаться динамически, во время работы программы, система предоставляет развитые средства контроля типов во время выполнения, которые позволяют писать универсальные алгоритмы обработки данных, не зависящие от конкретных типов этих данных (например, библиотека для работы с СУБД может предоставлять методы, записывающие результат запроса из базы в запись произвольной структуры, если набор и типы полей этой записи соответствуют набору и типам полей в БД).
                                                                                                            [...] Объектно-ориентированное программирование

                                                                                                            Средства объектного программирования интерпретируются в Обероне как естественное развитие средств работы с записями в модульной системе, точнее, как технический инструментарий для решения конкретной архитектурной задачи: обеспечить эффективное «разделение труда» между различными модулями при работе с динамическими типами и структурами данных: например, работа с указателями в списке может быть скрыта (вместе с соответствующими полями) в одном модуле, а определение и работа с конкретным «наполнением» элементов списка — задаваться в другом (или, чаще, других). В этом смысле технология объектного программирования в Обероне подчинена концепции модульности: она здесь является, скорее, средством описания данных, чем средством построения архитектуры приложения в целом.

                                                                                                              0
                                                                                                              Так что такое ООП? И как может быть ООП в языке, не имеющем объектов?
                                                                                                              ООП — это стиль программирования. Его можно использовать хотя на ассемблере, реализовав всю поддерживающую инфраструктуру. ООП ориентированный язык уже содержит поддержку этого стиля.
                                                                                                              Что касается высказываний апологетов функционального программирования в адрес ООП, то их аргументы могут выглядеть красиво в ряде ограниченных случаев, но как только дело доходит до реальных применений, где просто невозможно избежать наследования данных и множества композитов, то тут они просто тихо сливаются. Собственно, ООП не отвергает ФП, а просто использует его как часть общей идеологии. В отличие от.
                                                                                                                +1
                                                                                                                реальных применений, где просто невозможно избежать наследования данных и множества композитов

                                                                                                                Это каких, например?

                                                                                                                  0
                                                                                                                  Возьмите любой пример из своей/чужой практики где число предков о объекта больше 2-3х и объект содержит другие как композитные.
                                                                                                                    +1

                                                                                                                    Я не смог вспомнить ни одного такого примера (если вы не про глубину иерархии, хотя там, впрочем, вспомнить тоже очень тяжело, и наследование там костыль для косячного code reuse).


                                                                                                                    Содержать другие объекты как композитные вам никто не мешает и в рамках функционального подхода, например. А учитывая, что вы содержите объекты не ради их состояния, а ради их поведения, то всё выливается в обычную композицию функций.

                                                                                                                      +1
                                                                                                                      Я не смог вспомнить ни одного такого примера
                                                                                                                      Значит просто не сталкивались. У меня задачи проектирования и моделирования запросто уходили на 5-6 уровней наследования и до нескольких десятков композитов (только на одном уровне, а с наследованием еще больше) — это просто отображение реальных объектов и процессов.
                                                                                                                      всё выливается в обычную композицию функций
                                                                                                                      Хорошо, когда над объектом нужно выполнить одну-две операции, а когда их больше и нужно, кроме всего прочего, поддерживать/контролировать целостность, связанность и непротиворечивость данных, то ООП становится вне конкуренции, т.к. позволяет держать все в «одном месте», а при поддержке языка, еще ограничить стороннего программиста от желания «поковыряться внутри».
                                                                                                                        +1
                                                                                                                        5-6 уровней наследования и до нескольких десятков композитов (только на одном уровне, а с наследованием еще больше) — это просто отображение реальных объектов и процессов.

                                                                                                                        Что есть отображение реальных процессов которые нельзя выразить без наследования? Мне в голову пока лишь квадрат с прямоугольником, да собака с млекопитающим и т.п. лезет, и в обоих случаях можно обойтись без наследования.

                                                                                                                        невозможно избежать наследования данных

                                                                                                                        Хорошо, когда над объектом нужно выполнить одну-две операции, а когда их больше и нужно, кроме всего прочего, поддерживать/контролировать целостность, связанность и непротиворечивость данных

                                                                                                                        Наследовнание данных это просто наследование структур, наследованием в ООП обычно называют наследование поведения, и действия производятся объектом, а не «над» объектом

                                                                                                                        ООП становится вне конкуренции, т.к. позволяет держать все в «одном месте»

                                                                                                                        Что и в каком месте, почему при композиции всё не в одном месте?

                                                                                                                        Если объект большой, может его вообще стоит декомпозировать на логические части с минимальной связностью без наследований и композиций?
                                                                                                                          0
                                                                                                                          Мне в голову пока лишь квадрат с прямоугольником, да собака с млекопитающим и т.п. лезет
                                                                                                                          Описывать имеющуюся систему у меня нет возможности, но речь идет о поведенческих моделях, где на верхнем уровне абстракции имеются лишь самые общие свойства. На втором уровне появляются несколько конечных и несколько абстрактных объектов с новыми свойствами. Аналогично третий и четвертый уровни. Пятый и шестой уровни, в основном, описывает уже очень сложные композитные системы, которые, тем не менее, все еще прекрасно могут быть поняты функциями, работающими с предыдущими уровнями.
                                                                                                                          Причин сомневаться в ошибочности построенной модели нет, т.к. более чем десятилетняя ее эксплуатация не выявила каких-либо недостатков ни в процессах использования, ни в процессах расширения функционала.
                                                                                                                          почему при композиции всё не в одном месте
                                                                                                                          Когда композиция является частью объекта, никаких проблем не возникает.
                                                                                                                          0
                                                                                                                          У меня задачи проектирования и моделирования запросто уходили на 5-6 уровней наследования

                                                                                                                          Можно пример-то? Я тоже всякое-разное моделировал и проектировал, но там наследование никогда не уходило глубже одного уровня (если интерфейсы не брать в расчёт, а интерфейсы — костыль против отсутствующих тайпклассов так-то). Да и там зачастую алгебраические типы данных бы лучше подошли, но с ними в плюсах работать больно.


                                                                                                                          до нескольких десятков композитов

                                                                                                                          К композитам-то как раз никаких вопросов.