Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. [...] Вот только в ежедневной работе программисты другими вещами занимаются.
Не говорите за всех. Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются. В то же время именно научные учреждения обеспечивают прогресс в программировании. Т.о. это с Вашей стороны «диверсия» приземлять всё до уровеня промышленной разработки :)
Далее слишком много путаницы
Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете?
Вижу, что не потрудились открыть статью — там не так много рисунков. Этот Вы бы заметили.
В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев.
Абсурд так говорить о задаче для образования.
Это к вашему изначальному непониманию чем сообщения удобнее методов
Или к Вашему изначальному непониманию, чем методы удобнее сообщений ;)
Цитату можно найти в The Early History Of Smalltalk
А выше сказали:
Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.
И опять сказали:
И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk
Так имеет Smalltalk отношение к сути вопроса или не имеет? — Похоже, что Вы сами запутались :)
BTW:
Первым языком программирования, в котором были предложены основные понятия [ООП], впоследствии сложившиеся в парадигму, была Симула
Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.
Вот случай мифа о котором в статье:
метафора, которую попытались возвести в статус религии.
Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП. А еще говорите о промышленной разработке!
я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.
У Вас
sendMsgAsync(eventLogger, event)
Где у меня eventLogger?
Более того Вы ж сказали, что возьмете не мой, а свой пример:
Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
Очевидно прокинуть эвент для обработки ряду объектов.
Опять запутались!
И «прокинуть эвент для обработки ряду объектов» это не
Разумеется конкретному,
Снова запутались?!
Далее я спросил:
Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?
Вы ответили классически вопросом на вопрос:
И что?
Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет. Не буду комментировать такой абсурд.
Т.о., к сожалению, никаких доводов, кроме исторических, про преимущество обмена сообщениями в ООП я не услышал. Скорее услышал контрдоводы. Сейчас основное направление ООП не обмен сообщениями между объектами. В статье я исходил из этого основного направления и продолжу его придерживаться.
Ну так выделение памяти и т.д и происходит при вызове конструктора (речь про вызов в исходном коде!). Пока нет вызова прога не знает, что нужен новый объект. Можно в отладчике ассемблерный код посмотреть.
Подробнее
Ставите «бряк» на строке:
dg := TDirectedGraph.create;
Открываете окно CPU и далее шагаете по коду с говорящими именами:
@getMem
call @classCreate
TObject.NewInstance
call TObject.InstanceSize
call @GetMem
call dword ptr [MemoryManager]
SysGetMem
call TObject.Create
и т.д.
Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:
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, то дальше код не пойдёт.
Т.е. никакой из существующих ЯП такой механизм не использует? Попытаюсь расшифровать этот псевдокод:
Посылаю асинхронно сообщение event через eventLogger. Если функция sendMsg возвращает ложный статус — остановить программу. Кортежам «статус, событие» и «статус, отклик» присвоить «обогатитель» (?) события и хандлер события. И зачем нам такие кортежи? Полный туман:
1) sendMsgAsync посылает сообщение определенному объекту (объектам) или всем объектам в инете?
2) Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?
3) Должен быть единый список сообщений, понятный всем объектам?
4) Какой формат сообщения? (сколько в нем полей, символов, целых и нецелых чисел и т.д.)
5) Если сообщения в инете, то они должны шифроваться для безопасности?
Много чего есть…
Я не про всё, что есть. А про ОО подход, который представляется ИМХО более совершенным, чем обмен сообщениями.
Почитайте статью, которую вы упустили из виду.
Не упустил, но и при повторном прочтении не увидел там особо интересной информации по теме. Речь там о незнакомом мне ЯП «в ответ на вопрос о парадигме языка». М.б. кто знает этот язык — тому интересно. А у меня даже общего представления не сложилось. Есть много статей на подобные узко-специальные темы, почему я должен был не упустить и упомянуть именно эту?
Да. Он скрыт, но память под объект должна выделяться динамически при вызове конструктора.
Динамически создаваемые объекты, как правило, размещаются в куче, что менее эффективно, чем размещение их на стеке и, тем более, статическое выделение памяти под них на этапе компиляции.
Вызов TDirectedGraph.create (и т.д.) в обработчике события создания окна — обработчик TMainForm.FormCreate, но create, создающий экземпляр (обект) типа TDirectedGraph, определено в TDirectedGraph.
Первоначально (например, в том же 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.
Есть еще контрактное программирование…
Ok. Естественное желание многих школьников сразу по окончании школы получать хорошую ЗП, а не тратить 5 лет на вуз. — Вот он и делится с сообществом своими мечтами.
Кто окончил вуз, но условно говоря торгует овощами — не обязательно за прилавком, а м.б. топ-менеджер крупной фирмы и через него каждый день проходят сделки на много тонн овощей и фруктов, видит, что кроме 4 арифметических действий никакая математика ему не нужна.
Но не все собираются всю жизнь торговать овощами и не все смогут найти работу топ-менеджера крупной фирмы. — Как повезет, кому «не повезет» — тому м.б. будет нужна математика :)
Для этого сделаем следующий простой обработчик события создания основной формы:
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 в другом месте.
объектам посылаются сообщения (которые также являются объектами)
Возьмем класс TRect из моего примера. Пусть в этом классе будет метод draw, отрисовывающий прямоугольник. Попробуем смоделировать передачу сообщения drawMsg («рисовать») с помощью данных:
sendMsg (toRect {куда}, drawMsg {сообщение});
Не вижу преимуществ такого кода: ни доп. надежности, ни масштабируемости.
В объектно-ориентированном программировании конструктор класса (от англ. constructor) — специальный блок инструкций, вызываемый при создании объекта.
На старте программе м.б. неизвестно сколько каких объектов будет нужно. Значит придется динамически создавать (и уничтожать) по мере необходимости в ходе выполнения.
Кроме скорости: чем лучше создавать объект-сообщение конструктором, а потом уничтожать его деструктором? Разве это не потребует больше строчек исходного кода?
Вопросы про мой кругозор пожалуй оставлю за кадром.
Ответ на этот вопрос м.б. много объяснит. Почему Вы считаетет, что можете не отвечать на мой закономерно возникший вопрос, но требуете ответы у меня на совершенно надуманные вопросы?
трактовку этого термина вы не привели
Я не обязан приводить трактовку — я привел ссылки на инструменты, где реализованы похожие трактовки и этого достаточно. У меня, нпр., есть «координаты точки» — потребуйте еще трактовку этого термина и, заодно, термина «програмирование» ;))
этой статье никакой конкретики я не вижу.
Хотя и в предыдущих ее не сильно много то. Так, в комментиках поспорить.
У Вас, видимо, своеобразное понимание конкретики, если в 4 статьях с большими просмотрами и обсуждениями не увидели конкретики, то помочь Вам не смогу.
Смотрите внимательнее. В самом начале я указал 3 недавних статьи, высказывающие противоположные мнения на данную тему. Это не конкретика? Далее привел «показательный типичный комментарий» и т.д. Что м.б. конкретнее? Вы даже в начале этой конкретики не увидели, поэтому возникает закономерный вопрос: статью читали?
Пока в статье используются термины не имеющие однозначной трактовки
Как такое возможно?: в конкретном ЯП, нпр., Delphi 7 важный термин, нпр., наследование не имеет однозначной трактовки? — Явный абсурд!
Далее у Вас не менее абсурдное заявление:
Википедия во первых не источник правды
Кто Вам это сказал? К Вашему сведению Вики делают (пишут, редактируют, обсуждают) в том числе много очень грамотных людей, в том числе спецы мирового уровня. Все, что скзано в вики, должно быть подкреплено ссылками на авторитетные источники. Если что-то ситуативно не подкреплено, то будет подкреплено или будет удалено в ближайшее время.
во вторых также однозначной трактовки не даёт.
Подымите первоисточник. Где в указанной статье вики неоднозначные трактовки терминов, которые в моей статье? Вы пытаетесь обвинять меня в отсутвии конкретики, но сами предельно неконкретны, поэтому все Ваши обвинения звучат голословно и бездоказательно.
Кто-то ещё пишет проекты на Паскале?
Много кто пишет. Поиск на Хабре и Гугл Вам в помощь :) Сами какой ЯП знаете? После Ваших заявлений возникает подозрение, что Ваш кругозор дальше одного языка не простирается.
У статьи нет пометки «Tutorial», т.о. предполагается, что читатель в достаточной степени владеет предметом — хотя бы в объеме статьи в Википедии.
нам что-то пытаются рассказывать про плюсы и минусы мифического инструмента X
См. статью — указаны реальные (не мифические) инструменты:
Буду исходить из умеренного простого подхода ОО Паскаля, заложенного еще в Turbo Pascal 5.5 и окончательно оформившегося к Delphi 7 (можно отметить и близкие по концепции ЯП других производителей, например, Think Pascal для MacOS).
даже не рассказывая что это за инструмент
Выше указал, что не «Tutorial». Про Object Pascal (Delphi и т.д..) надеюсь большинство читателей знает.
приправляя всё это сказами про наследование классов
А где доказательство, что изначальная концепция лучше «упрощенной»? (м.б., нпр., ЯП, отвечающие изначальной концепции, пользуются большим спросом и т.д.)
Не говорите за всех. Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются. В то же время именно научные учреждения обеспечивают прогресс в программировании. Т.о. это с Вашей стороны «диверсия» приземлять всё до уровеня промышленной разработки :)
Абсурд так говорить о задаче для образования.
Или к Вашему изначальному непониманию, чем методы удобнее сообщений ;)
А выше сказали:
И опять сказали:
Так имеет Smalltalk отношение к сути вопроса или не имеет? — Похоже, что Вы сами запутались :)
BTW:
Вот случай мифа о котором в статье:
Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП. А еще говорите о промышленной разработке!
У Вас
Где у меня eventLogger?
Более того Вы ж сказали, что возьмете не мой, а свой пример:
Опять запутались!
И «прокинуть эвент для обработки ряду объектов» это не
Снова запутались?!
Далее я спросил:
Вы ответили классически вопросом на вопрос:
Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет. Не буду комментировать такой абсурд.
Т.о., к сожалению, никаких доводов, кроме исторических, про преимущество обмена сообщениями в ООП я не услышал. Скорее услышал контрдоводы. Сейчас основное направление ООП не обмен сообщениями между объектами. В статье я исходил из этого основного направления и продолжу его придерживаться.
dg := TDirectedGraph.create;
Открываете окно CPU и далее шагаете по коду с говорящими именами:
@getMem
call @classCreate
TObject.NewInstance
call TObject.InstanceSize
call @GetMem
call dword ptr [MemoryManager]
SysGetMem
call TObject.Create
и т.д.
По сути:
В принципе я не против содержательной философии, но тут она явно избыточна и только наводит тумана. Нпр., я бы не стал называть переменную Х вещественного типа объектом. И я бы не назвал константу 3.14 обектом. И я бы не сказал, что операция присваивания переменной Х этого значения есть операция инициализации объекта:
И никакой инкапсуляции. И где тут сообщение? Но, наверное, есть подходы, где «Everything is an object.»
С этим не спорю.
ИМХО термин «бизнес-логика» размытый, плохой, нелепый. ИМХО очевидно: бизнес это деньги. В явном виде деньги не во всяком коде, а если и есть, нпр., в коде игры, то галактические кредиты 3300 г. — не те это деньги, которые хочет кодер) Поэтому ИМХО лучше использовать синоним: логика предметной области (domain logic). Иногда отрисовка «кнопочек», т.е. элементов контроля GUI это логика предметной области: нпр., клетки периодической таблицы (не обязательно прямоугольные).
Столь резкое утверждение нуждается в строгом доказательстве. (Возможно ли математически строго доказать, что технология Х — извращение? — Термин «извращение» не мат. термин, поэтому думаю, что это не более чем субъективные оценочные суждения, как с Вашей, так и с моей стороны. Большого значения они не имеют.)
См.:
Далее:
Т.е. никакой из существующих ЯП такой механизм не использует? Попытаюсь расшифровать этот псевдокод:
Посылаю асинхронно сообщение event через eventLogger. Если функция sendMsg возвращает ложный статус — остановить программу. Кортежам «статус, событие» и «статус, отклик» присвоить «обогатитель» (?) события и хандлер события. И зачем нам такие кортежи? Полный туман:
1) sendMsgAsync посылает сообщение определенному объекту (объектам) или всем объектам в инете?
2) Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?
3) Должен быть единый список сообщений, понятный всем объектам?
4) Какой формат сообщения? (сколько в нем полей, символов, целых и нецелых чисел и т.д.)
5) Если сообщения в инете, то они должны шифроваться для безопасности?
Я не про всё, что есть. А про ОО подход, который представляется ИМХО более совершенным, чем обмен сообщениями.
Не упустил, но и при повторном прочтении не увидел там особо интересной информации по теме. Речь там о незнакомом мне ЯП «в ответ на вопрос о парадигме языка». М.б. кто знает этот язык — тому интересно. А у меня даже общего представления не сложилось. Есть много статей на подобные узко-специальные темы, почему я должен был не упустить и упомянуть именно эту?
См.:
Далее:
Рисование графических примитивов очень важная практическая цель любого универсального программирования, нпр., для GUI.
tive will be prosecuted; persons attempting to find a
moral in it will be banished; persons attempting to
find a plot in it will be shot.
BY ORDER OF THE AUTHOR,
Per G.G., Chief of Ordnance.
Какой это ЯП? Что означает в ":ok" двоеточие? что значат фигурные скобки в "{:ok, event} = sendMsg(eventEnricher, event)"?
Чем это отличается от передачи событий ОС, нпр., Виндов ХР? Для обменов клиент-сервер обычно применяют технологии типа COM и, даже, CORBA.
Есть еще контрактное программирование…
Кто окончил вуз, но условно говоря торгует овощами — не обязательно за прилавком, а м.б. топ-менеджер крупной фирмы и через него каждый день проходят сделки на много тонн овощей и фруктов, видит, что кроме 4 арифметических действий никакая математика ему не нужна.
Но не все собираются всю жизнь торговать овощами и не все смогут найти работу топ-менеджера крупной фирмы. — Как повезет, кому «не повезет» — тому м.б. будет нужна математика :)
Здесь при создании основной формы создается 1 орграф, 1 неориентированный и 1 неориентированный большой. Позже могу заказать программе с консоли сделать еще 100 орграфов, а предыдущие удалить для экономии памяти. А инициализация dg, ug и bg в другом месте.
Возьмем класс TRect из моего примера. Пусть в этом классе будет метод draw, отрисовывающий прямоугольник. Попробуем смоделировать передачу сообщения drawMsg («рисовать») с помощью данных:
Не вижу преимуществ такого кода: ни доп. надежности, ни масштабируемости.
На старте программе м.б. неизвестно сколько каких объектов будет нужно. Значит придется динамически создавать (и уничтожать) по мере необходимости в ходе выполнения.
Просто убойный вывод!
+сказано: инкапсуляция, полиморфизм.
Не продолжайте.
Ответ на этот вопрос м.б. много объяснит. Почему Вы считаетет, что можете не отвечать на мой закономерно возникший вопрос, но требуете ответы у меня на совершенно надуманные вопросы?
Я не обязан приводить трактовку — я привел ссылки на инструменты, где реализованы похожие трактовки и этого достаточно. У меня, нпр., есть «координаты точки» — потребуйте еще трактовку этого термина и, заодно, термина «програмирование» ;))
У Вас, видимо, своеобразное понимание конкретики, если в 4 статьях с большими просмотрами и обсуждениями не увидели конкретики, то помочь Вам не смогу.
Смотрите внимательнее. В самом начале я указал 3 недавних статьи, высказывающие противоположные мнения на данную тему. Это не конкретика? Далее привел «показательный типичный комментарий» и т.д. Что м.б. конкретнее? Вы даже в начале этой конкретики не увидели, поэтому возникает закономерный вопрос: статью читали?
Как такое возможно?: в конкретном ЯП, нпр., Delphi 7 важный термин, нпр., наследование не имеет однозначной трактовки? — Явный абсурд!
Далее у Вас не менее абсурдное заявление:
Кто Вам это сказал? К Вашему сведению Вики делают (пишут, редактируют, обсуждают) в том числе много очень грамотных людей, в том числе спецы мирового уровня. Все, что скзано в вики, должно быть подкреплено ссылками на авторитетные источники. Если что-то ситуативно не подкреплено, то будет подкреплено или будет удалено в ближайшее время.
Подымите первоисточник. Где в указанной статье вики неоднозначные трактовки терминов, которые в моей статье? Вы пытаетесь обвинять меня в отсутвии конкретики, но сами предельно неконкретны, поэтому все Ваши обвинения звучат голословно и бездоказательно.
Много кто пишет. Поиск на Хабре и Гугл Вам в помощь :) Сами какой ЯП знаете? После Ваших заявлений возникает подозрение, что Ваш кругозор дальше одного языка не простирается.
У статьи нет пометки «Tutorial», т.о. предполагается, что читатель в достаточной степени владеет предметом — хотя бы в объеме статьи в Википедии.
См. статью — указаны реальные (не мифические) инструменты:
Выше указал, что не «Tutorial». Про Object Pascal (Delphi и т.д..) надеюсь большинство читателей знает.
А где конкретно сказки? ;)