Comments 205
Стоит отметить, что в большинстве ЯП объектно-ориентированный подход упрощен настолько, что от изначальной концепции, когда объектам посылаются сообщения (которые также являются объектами), а первые на них реагируют, остался всего лишь вызов метода, что уже принципиально мало отличается от традиционного процедурного программирования.
Вы так говорите, как будто это что-то плохое.
взять только самые удобные
Нет, конечно, это не плохо и не хорошо. Вызов метода просто оказался удобнее, и потому этим мы пользуемся сейчас.
Не удобнее, а проще в реализации с приемлемой скоростью. Впрочем, с тех пор уже столько лет утекло, что теперь единственным аргументом за вызов метода остался "привычнее".
Обычно ни конструктор не создаёт объект, ни деструктор его не уничтожает. Первый его инициализирует, втрой — очищает.
В объектно-ориентированном программировании конструктор класса (от англ. constructor) — специальный блок инструкций, вызываемый при создании объекта.
На старте программе м.б. неизвестно сколько каких объектов будет нужно. Значит придется динамически создавать (и уничтожать) по мере необходимости в ходе выполнения.
Именно "при создании", а не "для создания". Конструктор объект не создаёт. Из мэйнстрим языков разве что в JS конструктор может опционально создавать новый объект, а не инициализировать созданный рантаймом
Для этого сделаем следующий простой обработчик события создания основной формы:
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 в другом месте.
Я думаю, VolCh справедливо имеет в виду, что основной этап создания объекта — это аллокация памяти для него. В большинстве ЯП этот этап скрыт и не прописывается в конструкторе.
Динамически создаваемые объекты, как правило, размещаются в куче, что менее эффективно, чем размещение их на стеке и, тем более, статическое выделение памяти под них на этапе компиляции.
Не при вызове конструктора, а при вызове оператора new или аналога. Создание объекта, грубо:
- выделение памяти под объект и ссылку
- создание объекта и ссылки на него
- вызов конструктора, с передачей ссылки/указателя в качестве this, self и т. п.
- возврат ссылки
dg := TDirectedGraph.create;
Открываете окно CPU и далее шагаете по коду с говорящими именами:
@getMem
call @classCreate
TObject.NewInstance
call TObject.InstanceSize
call @GetMem
call dword ptr [MemoryManager]
SysGetMem
call TObject.Create
и т.д.
Оговорка "как правило" вас не смутила?
Из мэйнстрим языков разве что в JS конструктор может опционально создавать новый объект, а не инициализировать созданный рантаймомВ С++ изначально тип
this не был константным в конструкторе и ему можно было присваивать… но это уже история сегодня, конечно…Сообщение — это вообще данные, причём тут конструкторы/деструкторы?
А лучше тем, что объекты, общающиеся передачей сообщений, не связаны жёстко друг с другом, соответственно на порядки проще становится писать надёжные и масштабируемые системы.
Сообщение — это вообще данныевыше было сказано иное:
объектам посылаются сообщения (которые также являются объектами)
Возьмем класс TRect из моего примера. Пусть в этом классе будет метод draw, отрисовывающий прямоугольник. Попробуем смоделировать передачу сообщения drawMsg («рисовать») с помощью данных:
sendMsg (toRect {куда}, drawMsg {сообщение});
Не вижу преимуществ такого кода: ни доп. надежности, ни масштабируемости.
выше было сказано иное
Было сказано, но не мной )
Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.
Возьмем класс TRect из моего примера.
Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги и животные? А авторов, которые такие примеры в книгах используют, разместят на большую доску позора. Всё это настолько безумно далеко от практических целей ООП, что дальше некуда. И на этих вырожденных и абсолютно бесполезных примерах любые преимущества (даже ООП vs ПП) высосаны из пальца.
Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
Очевидно прокинуть эвент для обработки ряду объектов.
sendMsgAsync(eventLogger, event)
:ok = sendMsg(eventValidator, event)
{:ok, event} = sendMsg(eventEnricher, event)
{:ok, response} = sendMsg(eventHandler, event)Пока преимуществ не видно?
Но давайте представим, что этим объектам не обязательно находится на одном сервере. В случае, с вызовом метода — это невозможно, все объекты должны быть в памяти процесса, чтобы можно было вызвать их методы. Для передачи сообщений такого ограничения нет, и все 4 объекта из примера могут находиться на разных серверах (масштабируемость из коробки).
Теперь представьте, что с объектом logger что-то случилось, например упал с ошибкой. Достаточное ли это условие, чтобы похерить всю обработку эвента? В большинстве систем обработка эвента гораздо важнее его логирования. Но чтобы обеспечить пропуск опциональных шагов, вам придётся каждый из их завернуть в try (мда, ппц как удобно). В случае с сообщениями, вы можете легко сделать sendMsgAsync и не ждать возврата результата, когда он не важен. Бонусом, вы получаете возможность все опциональные действия выполнять в отдельном потоке. А что будет с нашим упавшим из-за какого-то хитрого эвента логгером? А он зареспаунится с исходного состояния, без необходимости восстанавливать что-то после сбоя, без необходимости перемешивать обработку ошибок с бизнес-логикой и т.д.
Я в курсе сколько костылей напридумано, чтобы получить похожие результаты в ООП с вызовом методов. Однако для этого достаточно перейти на передачу сообщений между объектами.
Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.
См.:
Первоначально (например, в том же Smalltalk) взаимодействие объектов представлялось как «настоящий» обмен сообщениями, то есть пересылка от одного объекта другому специального объекта-сообщения.
Далее:
Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги [...] Всё это настолько безумно далеко от практических целей ООП, что дальше некуда.Рисование графических примитивов очень важная практическая цель любого универсального программирования, нпр., для 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.
Есть еще контрактное программирование…
Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:
- Everything is an object.
- Objects communicate by sending and receiving messages (in terms of objects).
- 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. Почитайте статью, которую вы упустили из виду.
Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:Из какого классического первоисточника это определение? Я встречал его во многих источниках — интересно какой был первый ;)
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;Как видите, тут нет никакого требования чтобы сообщения были объектами. Детали реализации 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) Если сообщения в инете, то они должны шифроваться для безопасности?
Много чего есть…Я не про всё, что есть. А про ОО подход, который представляется ИМХО более совершенным, чем обмен сообщениями.
Почитайте статью, которую вы упустили из виду.Не упустил, но и при повторном прочтении не увидел там особо интересной информации по теме. Речь там о незнакомом мне ЯП «в ответ на вопрос о парадигме языка». М.б. кто знает этот язык — тому интересно. А у меня даже общего представления не сложилось. Есть много статей на подобные узко-специальные темы, почему я должен был не упустить и упомянуть именно эту?
Из какого классического первоисточника это определение? Я встречал его во многих источниках — интересно какой был первый ;)
Тот, кто ввёл термин ООП (Алан Кэй), тот и был первым, очевидно же. Цитату можно найти в 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.
Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. [...] Вот только в ежедневной работе программисты другими вещами занимаются.Не говорите за всех. Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются. В то же время именно научные учреждения обеспечивают прогресс в программировании. Т.о. это с Вашей стороны «диверсия» приземлять всё до уровеня промышленной разработки :)
Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете?Вижу, что не потрудились открыть статью — там не так много рисунков. Этот Вы бы заметили.
В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев.Абсурд так говорить о задаче для образования.
Это к вашему изначальному непониманию чем сообщения удобнее методовИли к Вашему изначальному непониманию, чем методы удобнее сообщений ;)
Цитату можно найти в The Early History Of SmalltalkА выше сказали:
Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.
И опять сказали:
И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk
Так имеет Smalltalk отношение к сути вопроса или не имеет? — Похоже, что Вы сами запутались :)
BTW:
Первым языком программирования, в котором были предложены основные понятия [ООП], впоследствии сложившиеся в парадигму, была Симула
Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.Вот случай мифа о котором в статье:
метафора, которую попытались возвести в статус религии.Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП. А еще говорите о промышленной разработке!
я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.У Вас
sendMsgAsync(eventLogger, event)
Где у меня eventLogger?
Более того Вы ж сказали, что возьмете не мой, а свой пример:
Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
Очевидно прокинуть эвент для обработки ряду объектов.
Опять запутались!
И «прокинуть эвент для обработки ряду объектов» это не
Разумеется конкретному,
Снова запутались?!
Далее я спросил:
Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?
Вы ответили классически вопросом на вопрос:
И что?
Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет. Не буду комментировать такой абсурд.
Т.о., к сожалению, никаких доводов, кроме исторических, про преимущество обмена сообщениями в ООП я не услышал. Скорее услышал контрдоводы. Сейчас основное направление ООП не обмен сообщениями между объектами. В статье я исходил из этого основного направления и продолжу его придерживаться.
Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются.
Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.
Так имеет Smalltalk отношение к сути вопроса или не имеет?
Есть абстрактная идея ООП, а есть её реализации. Поскольку вы хотите не только теорию, но и конкретику, то вам придётся ознакомиться и с реализациями ООП:
Smalltalk — классическая class-based реализация ООП
Erlang/OTP — actor-based реализация ООП
При этом то, что справедливо для конкретной реализации, не всегда справедливо для парадигмы как таковой.
Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП.
Да в принципе никакое, пока вы сами по себе что-то там пишете, можете хоть своим личным ООП руководствоваться. Но раз взялись писать статью, то потрудитесь хоть немного разобраться в теме, прежде чем писать о ней. И нет, прочитать одну статью на википедии недостаточно.
У Вас
sendMsgAsync(eventLogger, event)
Где у меня eventLogger?
Более того Вы ж сказали, что возьмете не мой, а свой пример
OMFG, вы читать вообще умеете, я же русским языком написал, что взял синтаксис из вашего примера, чтобы вам понятнее было. Напоминаю:
sendMsg ({куда}, {сообщение});
И «прокинуть эвент для обработки ряду объектов» это не
Разумеется конкретному,
Каждая строка отправляет сообщение конкретному объекту, а все вместе они образуют ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)
Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет.
О чём вы вообще говорите? Какие миллионы компов всей Земли? Хоть это и происходит, но это вообще не в тему обсуждения. Вы вообще понимаете, что такое горизонтальное масштабирование системы? Или кроме desktop-приложений на Delphi ничего не делали?
Пример нападок:
Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.
И это Вы заявили при явном отсутствии информации (когда другой на Вашем месте промолчал бы до получения большей информации). Будет Вам известно, что те самые кружочки могут обозначать вершины молекулярных графов или атомы. А изучение таких графов позволяет, нпр., проектировать вещества с заранее заданными свойствами, нпр., новые лекарства.
Что касается фанатизма, то здесь первым делом нужно отметить Вашу убежденность в превосходстве промышленной разработки над научной и в том, что сообщения удобнее методов. Вы даже не понимаете что тут доказывать — произносите слово «логер» и Вам кажется, что каждый должен склоняться перд ним в трепете. А между тем Вы даже задачу толком не сформулировали. Так и осталось непонятным зачем этот ряд:
ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)
М.б. и попытались что-то объяснить, но с объяснениями, как и с доказательствами у Вас явно не получается. Про свой вывод о Вашей трактовке ООП я уже сказал в предыдущем комменте.
Будет Вам известно, что те самые кружочки могут обозначать вершины молекулярных графов или атомы. А изучение таких графов позволяет..
Вы в упор не читаете, что вам пишут. Речь была про примеры, на которых зачастую объясняют ООП в учебниках. Вы сначала убеждали, что они прекрасны, и ничего сложнее для понимания ООП не надо. А теперь обижаетесь на простые логические выводы из ваших же слов. Я же вам пытаюсь объяснить, что ООП придумали не для простых задач, а для того чтобы упростить решение сложных. Поэтому именно сложные задачи необходимо рассматривать и в учебниках, иначе у людей формируется искажённое понимание ООП.
Что касается графов, их изучение и отрисовка — это 2 несвязанные задачи.
первым делом нужно отметить Вашу убежденность в превосходстве промышленной разработки над научной
Вообще ничего подобного. Научная разработка она просто другая. Зачем сравнивать тёплое с мягким. Единственный факт, на который стоило бы обратить внимание, что в научной разработке занято на порядок, а то и на пару порядков, меньше людей. Поэтому при обсуждении примеров для массовых учебников и статей, разумнее опираться на промышленную обработку. Это не вопрос какого-то мнимого превосходства, это просто вопрос здравого смысла.
Так и осталось непонятным зачем этот ряд
Вы английский знаете? У каждого из этих объектов одна ответственность, которая выражена в его названии.
Можно было бы тоже статью накатать с подробной расшифровкой, но я не вижу в этом смысла. Кто сталкивался с подобным классом задач, тот и так поймёт что я написал. А кто не сталкивался — ну может им и не надо. Собственно, может им и ООП не надо.
Что касается графов, их изучение и отрисовка — это 2 несвязанные задачи.Кто Вам сказал такую абсурдную вещь? Если изучаете конкретный граф, то его ввести в комп сначала надо. И как быть? Писать на бумажке матрицу смежности или сразу на экране рисовать, а матрицу комп сообразит?
Я же вам пытаюсь объяснить, что ООП придумали не для простых задач, а для того чтобы упростить решение сложных.А я Вам пытаюсь объяснить, что если можно упростить задачу, для объяснения — это надо сделать. Есть такой риторический прием добавить туману, чтобы сложнее понять было, а начинаешь разбираться — задачка оказывается элементарной. И, опять, кто Вам сказал, что ООП придумали не для простых задач? Во многих задачах ООП используется для очень простого GUI. Да и в целом, простых задач повсюду решают гораздо больше, чем сложных.
именно сложные задачи необходимо рассматривать и в учебникахУверен, что большинство учителей с Вами не согласятся, т.к. принцип «от простого к сложному» хорошо себя зарекомендовал.
А теперь обижаетесьЯ не обижаюсь. А только привел пример Ваших нападок не на тему статьи.
Научная разработка она просто другая. Зачем сравнивать тёплое с мягким.Что значит «просто другая»? Там что: другие компы, другие ОС, другие ЯП?
Единственный факт, на который стоило бы обратить внимание, что в научной разработке занято на порядок, а то и на пару порядков, меньше людей.Да, и эти люди обычно решают наиболее сложные задачи.
Поэтому при обсуждении примеров для массовых учебников и статей, разумнее опираться на промышленную обработку.Нет. В пром. разработках очень много тривиальных задач.
Вы английский знаете?Да.
У каждого из этих объектов одна ответственность, которая выражена в его названии.Названия осмыслены, но смысла задачи они не раскрывают.
Можно было бы тоже статью накатать с подробной расшифровкой, но я не вижу в этом смысла. Кто сталкивался с подобным классом задач, тот и так поймёт что я написал.С тем же неуспехом можно написать пару строк с именами input, output и сказать: кто сталкивался — тот поймёт.
Если изучаете конкретный граф, то его ввести в комп сначала надо.
Так ввести (в виде данных), или вывести на монитор в виде картинки? Вы уж определитесь там..
И, опять, кто Вам сказал, что ООП придумали не для простых задач?
Это просто факт. Читайте первоисточники.
Что значит «просто другая»? Там что: другие компы, другие ОС, другие ЯП?
То и значит. Разные условия, разные цели, разные типы задач, разные процессы разработки. Да и языки другие, для научной разработки лучше всего подходят Haskell, Idris, Matlab, Fortran, etc. Julia вон недавно завезли, не пробовали ещё?
А ООП вам там в подавляющем большинстве задач нафиг не сдалось, если честно. Научная разработка — вотчина ФП (чистая математика, самый сок) и ПП (там где скорость критична, а алгоритмов с неизменяемыми данными не хватает).
Да, и эти люди обычно решают наиболее сложные задачи.
Это смотря по каким критериям измерять сложность. Вы лишь сравниваете что зеленее? тёплое или мягкое?
Посади тех же людей, которые решают сложные научные задачи, писать промышленный проект средней руки, и они облажаются по полной. Так же как и в обратную сторону.
В пром. разработках очень много тривиальных задач.
Можно подумать в научных мало… Все расчёты сводятся в конечном итоге к большому кол-ву тривиальных задач.
Это неважно. Важно, что нетривиальных задач тоже много.
Так ввести (в виде данных), или вывести на монитор в виде картинки?Когда Вы картинку в Фотошопе редактируете, Вы эту картинку на экране видите? Чем отличается картинка графа? (Только редактор другой).
Это просто факт. Читайте первоисточники.Лет 20-30 назад, кто-то из теоретиков написал, а Вы ему поверили?
Далее мне стало скучно отвечать на столь примитивную риторику.
Лет 20-30 назад, кто-то из теоретиков написал, а Вы ему поверили?
Далее мне стало скучно отвечать на столь примитивную риторику.
На кто-то из теоретиков, а автор термина, «мифы» о котором вы решили «развеять», и не только 20 и 30 лет назад, а он до сих пор жив и до сих пор имеет мнение по этому поводу.
Постыдились бы лучше своего невежества да нежелания разбираться в теме и слушать людей вокруг, чем демагогию разводить, да пытаться уже 3-их собеседников выставить непонимающими путем выдергивания их фраз и подмены контекста.
слушать людей вокруг
Т.е. Вас, который ранее уже попрощался и зачем-то вернулся, и Source, который ушел из темы в обсуждение моей персоны? ;) — Прекрасный ассортимент! А главное многочисленный :)))
1. Нет, я лишь знаком с его мыслями, и знаком с текущим, «популярным» ООП и понимаю почему оно таковым не является. Вам, насколько я помню, приводили пример статьи с комментарием от Армстронга, да и в целом информация гуглится. А банально, не знание кто такой Алан Кей, со стороны автора который решил миру про ООП вещать это невежество.
2. Догматизма в моих высказываниях не было. Вы снова пытаетесь подменить смысл моих слов на очевидно абсурдный и опровергать мнение которого я не высказывал. Чистейшая демагогия.
Как минимум, мы должны безоговорочно верить его определению термина и объяснению зачем он нужен. Если не верим, то просто надо придумать другой термин.
мы должны безоговорочно верить его определению
Почему? Учитывая, что:
ООП имеет уже более чем сорокалетнюю историю, но, несмотря на это, до сих пор не существует чёткого общепринятого определения данной технологии[14]. Основные принципы, заложенные в первые объектные языки и системы, подверглись существенному изменению (или искажению) и дополнению при многочисленных реализациях последующего времени. Кроме того, примерно с середины 1980-х годов термин «объектно-ориентированный» стал модным, в результате с ним произошло то же самое, что несколько раньше с термином «структурный» (ставшим модным после распространения технологии структурного программирования) — его стали искусственно «прикреплять» к любым новым разработкам, чтобы обеспечить им привлекательность.
Тем более. Если определение могло изменитья и исказться и теперь его начальное значение "потеряно", то вот ЗАЧЕМ эту штуку придумали измениться не могло
оказалось, что даже простенькую форму с одной кнопкой очень удобно генерировать автоматом, где код будет ОО.
Ну ведь всего пару часов назад речь шла о том что нет однозначного определения. ОО-код в формочке никакое на самом деле не ООП в том виде, в котором оно задумывалось, это просто использование классов для структурирования кода, ООП в классическом его определении от классов не появляется.
А речь шла не про определение, а про утверждение, что ООП придумали не для простых задач.
Если про это не написали в русской Википедии на странице про ООП, то для вас это неочевидно?
Я бы даже сказал, что не слишком громким обобщением, будет сказать, что в программировании уже лет 70 как ничего не придумывают для простых задач. Основной драйвер развития парадигм и инструментария — борьба со сложностью.
И именно на этой борьбе построили удачные маркетинговые компании, которые реализовали небольшое подмножество идей ООП, типа того же C++. Да с него плевались те, кто придумал ООП, писали "что за хрень?", но маркетинг сделал своё дело. Но это 35 лет назад можно было на что угодно навесить ярлык ООП, лишь бы продать. Сейчас любой желающий может ознакомиться с оригинальным описанием парадигмы, осознать масштабы концептуальных искажений в мейнстрим языках и сделать выводы. И практически применимые выводы, потому что ООП — это не технология, а парадигма — совокупность идей и понятий, определяющих стиль написания программ. Как только поймёте парадигму, сможете начать её применять в любом языке.
Теперь Вы можете сколько хватит сил призывать правильно использовать ООП только для сложных задач — Вас никто не станет слушать :))
Теперь Вы можете сколько хватит сил призывать правильно использовать ООП только для сложных задач — Вас никто не станет слушать :))
Кто-то не станет, а у кого-то ещё осталось собственное мышление и желание разобраться в вопросе, а не наследовать круг от овала потому что так в институте на курсе по «ООП» научили.
По поводу того что формочки это не ООП, это просто классы я писал, и против их использования из комментаторов никто не выступал но вы как всегда пропустили это мимо себя.
Поэтому именно сложные задачи необходимо рассматривать и в учебникахЭта проблема есть в обучении чему угодно. Всякие правила работы на токарном станке тоже объясняются на простых примерах, хотя они разработаны для сложных.
Ну просто потому что во время обучения время дорого и сложные примеры рассмотреть сложно.
Потому такая разная зарплата у людей, только что отучившихся, и у людей с опытом хотя бы в год-два.
иначе у людей формируется искажённое понимание ООП.Если у человака «гуманитарный склад мышления», то он везде найдёт способы всё неправильно проинтерпретировать:
Глупо из-за этого тратить полгода на изучение одного сложного примера, вместо того, чтобы пройти целый курс.К тому же на практике простые примеры встречаются чаще.
Кто сталкивался с подобным классом задач, тот и так поймёт что я написал. А кто не сталкивался — ну может им и не надо. Собственно, может им и ООП не надо.Там надо студентам рассказывать про ООП или не надо? И если надо — то стоит ли начать с логгеров до того, как они крожочек на экране смогли нарисовать?
Имхо, не стоит ничего объяснять на искусственных примерах. И да, это общий вопрос для любых концепций. Всегда можно найти достаточно простой пример, но при этом адекватный и практически применимый.
Проблема в примерах с фигурами и животными, в том, что они сами по себе являются примерами непонимания как и зачем применять ООП, примерами того, как делать не надо. При этом люди на них осваивают это самое ООП. А потом, когда они набираются опыта, пишут статьи типа "Чем быстрее вы забудете ООП, тем лучше для вас". А всё потому, что изначально учились на дрянных и совершенно неадекватных примерах.
Примеры разбора их неадекватности: 1, 2
ООП — полезная парадигма, но только если понимать зачем она была создана и для чего. А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.
Всегда можно найти достаточно простой пример, но при этом адекватный и практически применимый.Дык пресловутые прямоугольники и окружности — вполне практический и применимый пример. Любой векторный редактор поверх них устроен. Конечно не каждый студент будет делать в своей работе векторный графический редактор… Ну так то же самое можно про что угодно сказать.
Проблема в примерах с фигурами и животными, в том, что они сами по себе являются примерами непонимания как и зачем применять ООП, примерами того, как делать не надо.А как, извините, «делать надо». Вот хотите вы открыть SVG-файл и как-то научиться отображать его — как вы программу структурирует? Неужели без классов «линия» и «дуга окружности» обойдётся? Ну расскажите как это должно быть устроено — интересно же.
А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.Ну если вы, вдруг, «поняли дзен» — то расскажите как ваш «правильный» Inkscape будет отличаться от реально существующего. Только не надо к логгерам переходить, я вас умоляю: векторные редакторы тоже нужны — и если ваш ООП не позволяет их создать — то зачем это всё нужно?
Конечно не каждый студент будет делать в своей работе векторный графический редактор… Ну так то же самое можно про что угодно сказать.
Как сказать… Есть классы задач, которые решаются постоянно, ежедневно в тысячах компаний по всему свету, просто потому что универсального решения нет или пока не нашли, но есть универсальные принципы и подходы к их решению. И именно их было бы гораздо полезнее рассматривать в учебных целях. Нечто подобное рассматривают в книгах про паттерны проектирования.
Вот только это сложный и путанный путь: сначала объяснить ООП так, чтобы никто не понял зачем оно, а когда задолбается, начал паттерны изучать или переизобретать.
Обратите внимание, почти все паттерны выделяют объекты по поведению (поведение + данные, необходимые для его реализации), а почти все учебники и статьи для начинающих продолжают нести дичь про объекты реального мира и про то, что объект — это модель, это данные и всевозможные действия над этими данными (= фундаментальная ошибка понимания ООП).
P.S. Вы всерьёз думаете, что формат комментариев подходит для обсуждения создания векторного редактора с нуля? Мало того, что это практически бессмысленная задача (у вас бюджета не хватит подвинуть конкурентов), так она ещё и огромна.
Но раз уж вам захотелось дзена, то почитайте исходники того же Inkscape и ответьте на вопросы: Почему класс Circle не наследует от класса Shape? И не содержит метода draw? Авторы Inkscape не дураки, чтобы делать так, как описано в "учебниках" по ООП.
Но раз уж вам захотелось дзена, то почитайте исходники того же Inkscape и ответьте на вопросы: Почему класс Circle не наследует от класса Shape? И не содержит метода draw?Ответ, вообще-то, очевиден — только не таков, каким он вам кажется.
Авторы Inkscape не дураки, чтобы делать так, как описано в «учебниках» по ООП.Авторы Inkscape, вообще-то, начинали с исходников Sodipodi, созданном на языке C без использования ООП.
Разумеется когда вы добавляете ООП в уже существующий код — ваши руки оказываются «связанными».
Ответ, вообще-то, очевиден — только не таков, каким он вам кажется.
Если вы намекаете, что ответ — "исторически сложилось", то это неправильный ответ.
Авторы Inkscape, вообще-то, начинали с исходников Sodipodi, созданном на языке C без использования ООП.
Ох, как же вы живёте то теперь со знанием, что векторный редактор можно и без ООП написать xD
Кстати, в C вполне возможно использовать ООП (не забывайте, что это парадигма, и что наличие классов — не является её требованием)
Разумеется когда вы добавляете ООП в уже существующий код — ваши руки оказываются «связанными».
Что значит "разумеется"? Inkscape уж 15+ лет существует… пару раз что угодно переписать можно было, если бы была насущная необходимость.
Да и вообще когда есть понимание, как надо переделать и зачем, руки ничто не связывает.
А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.«Все врут календари» (С) :)))
Зависит от степени вашего формализма )))
Можно понимать первый пункт так:
Программа состоит из объектов, нет никакого кода, исполняющегося вне объектов.
При этом что там внутри объектов происходит (п.3) и как они коммуницируют (п.2) — темы отдельные и формально не требуют ни наличия объектов внутри own memory объекта, ни использования объектов для передачи сообщений.
Что плохого в том, чтобы из каждого ящика с инструментами взять только самые удобные
Ничего плохого, но ни слова про удобство в комментарии на который вы отвечаете не было, и далеко не факт что именно удобство стало причиной такого упрощения.
Вряд ли Smalltalk, реализующий кошерный ООП и написанный в 80-х был сильно непонятным или сложно реализуемым.Не «вряд ли», а «совершенно точно». Вы не могли, условно говоря, взять программу на FORTRAN и записать её на SmallTalk. Вся работа с плавучкой — через посылку сообщений, встроенным у него только
int был. И эффективность у него была, мягко говоря, не очень.А вот Turbo Pascal 5.5 — отлично работал на XT с 512K, а если очень надо было, то и на PC с 256K (среда не запускалась, но можно было использовать какой-нибудь другой редактор… Turbo Pascal 3.0, к примеру).
А сейчас компьютеры выросли, но мы работаем с «замечательным» гибридами: языками, которые выразительность взяли от Turbo Pascal 5.5, а эффективность — от Smalltalk'а. Потрясающая комбинация.
Кей писал что ST и его парадигма стали «чем-то таким чем нужно учиться», у Девида Веста ещё популярный доклад на эту тему где он маркетинг винит в уничтожении хороших идей.
изначальной концепции, когда объектам посылаются сообщения
а сигналы и слоты из Qt подходят под «изначальную концепцию»?
P.S. Скорее всего нет никакой абсолютной изначальной концепции…
Хорошо знать разные подходы и применять лучшие практики для конкретного класса задач.
И понимать, что все развивается, меняется, переосмысливается.
Экспериментам и ошибкам тоже есть место…
С каких пор это моветон? Там все API на них, от таймеров до UI. Тот же QML, кстати, весь по сути статический (определен заранее), но все на сигналах. Какое-то очень категоричное суждение получилось...
если же вы пишете конечный код с бизнес-логикой, для которого в момент написания известно, кто с кем как взаимодействует, то сигналы и слоты там не нужны (и именно поэтому я написал про «наперёд известных»).
ну во-первых, API Qt довольно-таки сильно привязан к сигналам/слотам. Бизнес-логика всё-таки имеет свойство взаимодействовать с GUI/БД/сетью/т.д. Во-вторых, абстрактные «наперед известные» объекты могут жить в разных потоках. Но соглашусь, что пересылать большой поток данных через сигналы/слоты может быть неуместно
В D можно принимать любые выводимые на этапе компиляции сообщения: https://tour.dlang.org/tour/en/gems/opdispatch-opapply
Смотря что считать динамической типизацией. Я как-то ради фана сделал что-то вроде true OOP на PHP, что вроде легко переводилось на Java/C#. Типизации вполне статическая, просто есть метод handleMessage(AbstractMessage message) у каждого класса.
Абсолютно правильно, как пример:
@interface Counter
-(NSInteger) increment;
@end
// Добавляем новый функционал через категорию -
// элемент языка, который служит для расширения
// функциональности класса.
@interface Counter (CountByTen)
-(NSInteger) incrementByTen;
@end
// И где то в коде.
Counter *counter = [[Counter alloc] init];
[counter incrementByTen];Если вас сильно заинтересовал язык, посмотрите доку Яббл о нем.
Интерпретируемые языки взлетели когда железо ещё дорогое было. Из 4-х первых языков высокого уровня, как-то доживших до наших дней, Lisp и BASIC — интерпретируемые, Fortran и Cobol — компилируемые.
Хотя, начиная с 1975 года, он стал основным языком для персоналок, где он входил в комплект поставки по умолчанию. То есть да, можно признать, что действительно взлетел.
LISP — тогда требовал специальных LISP-машин более чем вдвое превосходивших по цене тогдашнее типичное топовое железо: топовый компьютер в 1975 году стоил $20 тысяч (самый дешёвый стоил $439), а LISP-машина в те годы стоила от $50 тысяч. И потому имел узкое нишевое применение — там, где были эти LISP-машины (в 1975 году их было два с половиной десятка, и семь тысяч на 1988 год).
Хотя, конечно язык — признаю взлетел, но до современных компьютеров, был в очень узкой нише = в золотой клетке.
А для чего это может понадобиться — ну так можно придумать массу примеров.
Ну например жил-был у вас GUI, рассчитанный на мышь. И захотели вы сделать GUI для телефона. Во многих случаях вы можете просто обрабатывать touch как клик мышкой. Но в некоторых классах (уже существующих!) — хочется другого поведения.
В Objective C — это делается вот через расширения. Ну а в C++/Java — через фабрики-фабрик-фабрик с соответствующей потерей эффективности.
А поддержку тач-событий вот вы так просто взяли и запилили в этом случае?Для большинства контролов достаточно замапить их в сообщения мыши, специально обрабатывать нужно только где-нибудь в Edit Box'е.
Какой-то нереалистичный пример.Вообще-то это вполне себе пример «взятый из жизни»… другое дело что со временем поддержка iOS становится всё более важной (сегодня она, пожалуй, важнее, чем поддержка MacOS) и библиотеки начинают поддерживать тач нативно.
Но лет десять назад — такое вполне себе делали.
Допустим, есть какая-то сторонняя библиотека, которую уж очень нравится и хочется использовать. И во всем нашем коде используется типовой код использующий класс из библиотеки, значит выносим в отдельный метод. В той же Java этот метод будет жить в классе-хелпере (не бейте ногами с жавой не сильно знаком). А в обжективе можно расширить класс нужной нам типовой (для нас) функциональностью.
Допустим, есть какая-то сторонняя библиотека, которую уж очень нравится и хочется использовать. И во всем нашем коде используется типовой код использующий класс из библиотеки, значит выносим в отдельный метод. В той же Java этот метод будет жить в классе-хелпере (не бейте ногами с жавой не сильно знаком). А в обжективе можно расширить класс нужной нам типовой (для нас) функциональностью.
Расширять своей функциональностью класс из сторонней библиотеки? Странные… кхм… вкусы у вас.
Почему бы не сделать удобный интерфейс объявляющий нужную вам функциональность, и уже в его реализации использовать стороннюю библиотеку, или хотя бы просто декоратором функциональность расширять?
Никто не говорит о том, что я не делаю подобное через интерфейс.
Но объясните, пожалуйста, зачем мне декораторы, если я могу заимплементить протокол (интерфейс в терминах obj-c) уже существующему библиотечному классу? И в этой имплементации пользовать базовый функционал класса.
Так что, о вкусах не спорят. =)
final class есть и в интепретируемых )
изначальная концепция лучше «упрощенной»
Я такого не утверждал (ровно как и не стал бы утверждать обратного).
(м.б., нпр., ЯП, отвечающие изначальной концепции, пользуются большим спросом и т.д.)Языки, пользующиеся большим спросом — это не самые лучшие языки, а языки «попавшие в струю», извините.
C/C++ — взлетел вместе с Unix, Javascript — это Web, Java — это вообще в чистом виде «каша из топора», когда миллиарды долларов, вбуханных в поделку, которая была хуже альтернатив по всем параметрам, привели к тому, что после многих лет развития — она превратилась-таки в что-то, чем реально можно пользоваться…
Да собственно если бы хорошие языки были популярными, то C и C++ никогда бы не стали языками #2 и #3: они же ужасны!
Класс это не скопище функций и свойств, это таки логически обособленная единица кода и «обсасывания» временами вполне обоснованными могут быть.
Если вы обернёте весь код в класс MyProgram, это будет не ООП, а вполне себе императивщина
Умение строить дом никак не связанно с представлением о стенах, умение писать текст никак не связанно с тем что я понимаю под фразами...
Типа да, без разницы будете вы выделять в коде классы и интерфейсы, типы и монады, структуры и трейты либо что-то ещё, основная проблема в понимании что в какой класс/тип/трейт выделить и какие уровни абстракции использовать.
При восприятии классов как обёрток для методов и свойств это, имхо, сложновато будет сделать.
Вся эта чепуха придумана для разумного управления сложностью, и если нагромождения классов и наследований делают код нечитаемым, есть смысл обсуждать и искать решения десятилетиями, не?
Какой там язык сейчас рулит, кстати?
Но тема не раскрыта, как мне кажется.
правы все: [...] и противники, когда негодуют на возведение ООП в статус серебряной пули, абсолютного оружия.
Это широко известный миф:
Фредерик Брукс указывает, что наиболее сложной частью создания программного обеспечения является «…спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…»[22].
Еще: Экзистенциальный Вопрос „Что Есть Объект?“»
+ проблемы модельного подхода…
Если открыть википедию, то увидите что там уже 3 типа ООП методологии: классы, компоненты и прототипы.
Беда в том что разум 99% программистов ограничен только классами. Они в упор не хотят замечать существование альтернативных ООП концепций.
При этом побеждают на рынке те платформы, которые научились готовить ООП не только на классах, но и грамотно применять компонентные ООП подходы: Angular vs React, Drupal vs WordPress.
В концепции ООП прямоугольник сам должен уметь себя двигать (метод Move(area, dx, dy)) или его должен кто-то уметь двигать (класс Area с методом MoveRect(rect, dx, dy) / Move'T(T, dx, dy))?
Вот когда есть множество вариантов использования и появляются споры. Причина — следствие...
Если бы для решения одной задачи был бы только один способ, жить было бы не интересно!
А как правильно будет для данного примера? Интересно услышать мнение...
Да, профессионал всегда сможет аргументировать способ решения задачи!
Вот тут возникает типичная проблема: стиль школьника часто позволяет быстрее сдать выполненную работу. Причем сильно быстрее. Результат будет хреновым, но это заметят далеко не сразу, иногда через годы. Отсюда — поиски технологий (в т.ч. языков), позволяющие опытному кодеру не жертвовать скоростью кодинга ради качества.
Вот тут возникает типичная проблема: стиль школьника часто позволяет быстрее сдать выполненную работу. Причем сильно быстрее. Результат будет хреновым, но это заметят далеко не сразу, иногда через годы.Чаще препод замечает сразу — и не только плохой стиль, вернее его отсутствие, но и баги. И не принимает такую «работу» ;)
ИМХО байки о супергениальных школьниках — во многом еще один миф. Про поиски технологий согласен.
А при чем здесь препод? Я как препод могу заявить, что не обращаю внимания на стиль. Студенту итак сложно, а если его грузить стилем программирования, он вообще ничего не сделает, плюнет и пойдет в армию! )
Мы поступали не так. Мы давали на решение задачи много времени, при этом в процесс сдачи включали code review преподавателем. Задача считалась зачтенной, когда студент объяснял причины выбора того или иного способа написания. К самому способу мы не придирались, просто спрашивали. Но порождаемые неудачным написанием опасные баги (вроде утечек памяти) велели устранять.
Думаю, любой преподаватель укажет на это, но на зачет влиять не будет. В случае какой-нибудь школы программирования, конечно подобное недопустимо, как и любые другие общеизвестные правила написания кода.
Речь о среднестатистическом студенте, а не о специальности АСУ в МГУ… Вы в праве иметь собственный подход к преподаванию,, конечно же. Практика покащывает, что студент, который хочет программировать либо спросит, либо разберется, либо к нему другие пожелания преподавателя, в тч те, о которых, говорите Вы.
понижение качества образования… стоит не поставить одному студенту зачет — целая делегация отправляется в деканат
Замкнутый круг ещё более понижающий качество образования!
некоторые школьники считают, что сразу после окончания школы смогут писать код за хорошие деньги
Даже на Хабре, полно статей «нах мне математика?!» и «нах мне ВУЗ?!».
Даже на Хабре, полно статей «нах мне математика?!» и «нах мне ВУЗ?!».Хороший был бы аргумент, только это мнение исходит далеко не только от школьников, но и в большей степени от тех, кто в этом самом ВУЗе изучал эту самую математику, и пришёл к выводу, что в работе ему всё это в лучшем случае бесполезно.
кто в этом самом ВУЗе изучал эту самую математику, и пришёл к выводу, что в работе ему всё это в лучшем случае бесполезноПри этом не все укзывают какая у них работа. Нпр., около моего дома продуктовый магазин, и там одна девушка с высшим образованием овощами торгует…
Обычно статьи всё же «нах мне, программисту, математика?!» и «нах мне, программисту, ВУЗ?!»
Кто окончил вуз, но условно говоря торгует овощами — не обязательно за прилавком, а м.б. топ-менеджер крупной фирмы и через него каждый день проходят сделки на много тонн овощей и фруктов, видит, что кроме 4 арифметических действий никакая математика ему не нужна.
Но не все собираются всю жизнь торговать овощами и не все смогут найти работу топ-менеджера крупной фирмы. — Как повезет, кому «не повезет» — тому м.б. будет нужна математика :)
топ-менеджер крупной фирмы и через него каждый день проходят сделки на много тонн овощей и фруктов, видит, что кроме 4 арифметических действий никакая математика ему не нужна
third112, если он реально топ, а не свадебный генерал, который ничего не решает, то он имеет дело помимо прочего и с реальными финансами, с весьма специфическими формулами:
(на картинке не просто примитивный дебет-кредит на уровне ПТУ, а продвинутая бухгалтерия западного образца от Chartered Institute of Management Accountants)
Погуглите, что такое Corporate Finance.
ИМХО (учитывая количество вводных данных): кто-то должен уметь двигать прямоугольник. %)
Ну и…
Area.Move(object, dx, dy) => { object.Move(dx, dy) }
(эээ… на каком это я языке написал? ну надеюсь поняли что хотел сказать)
Более важно, на мой взгляд, вот что. Любая сущность, которую вводят в языках программирования, обладает определенными математическими свойствами. Эти свойства, если они удобны, позволяют проверять корректность кода и/или эффективно оптимизировать его при компиляции. Напротив, неудобные свойства приводят к путанице и либо провоцируют ошибки, либо заставляют перегружать код лишней писаниной, чтобы из имеющихся свойств построить желаемые.
В ООП не очень понятно, чем является класс. Это не множество. Это и не класс из математики. Наследование классов не дает ни надмножество, ни подмножество. Поэтому, когда с помощью ООП пытаются выразить типичные для множеств соотношения вроде "окружность — частный случай фигуры на экране", начинают требоваться особые и часто неинтуитивные приемы работы с ООП (часть из них известна как "пэттерны", часть — негласные, но всеми используемые приемы).
Поэтому важно не то, есть в названии языка слово "объектно-ориентированный" или нет, а то, построен ли язык вокруг какой-то удобной аксиоматики. Когда язык строят последовательным добавлением "а вот еще вот эту фичу", получаются внутренние противоречия и парадоксы. Совершенно понятно желание многих людей иметь язык программирования, свободный от парадоксального поведения.
Любая сущность, которую вводят в языках программирования, обладает определенными математическими свойствами.Сможете назвать мат. аналог понятию «файл»? Когда-то участвовал в обсуждении этого вопроса на кафедре высшей математики одного из знаменитых московских вузов — в том обсуждении никто не смог назвать точного мат. аналога. Т.о. ИМХО не все базовые понятия CS являются мат. понятиями. Хотя математика и CS имеют значительные пересечения, но, даже, природа этих наук разная: CS экспериментальная наука, а математика нет.
Ну, содержимое файла — конечное упорядоченное множество пар (номер, байт), операции над содержимым двух файлов, дописывание в файл соответствуют как минимум моноиду (ассоциативность есть, единичный элемент — пустой файл — есть). Имена файлов — граф, дерево. Точного названия для такой штуки в математике скорее всего нет, но многие аксиомы для свойств можно записать сразу.
Точного названия для такой штуки в математике скорее всего нетИ в том обсуждении, которое вспомнил, все сошлись на том, что «точного названия в математике нет», поэтому в CS есть нематематическая специфика. Без мат. методов CS не обойтись, но решить все задачи CS только мат. подходом не получится.
Скорее не так: "точного названия в математике пока не придумали". Ничто не мешает написать строгую аксиоматическую теорию файлов. Точно так же, как давным-давно была написана строгая аксиоматическая теория взамен рисования геометрических фигур палочкой на песке. Соответствующий математический объект будет называться "файл".
Ничто не мешает написать строгую аксиоматическую теорию файлов.Но почему-то никто не пробует написать такую теорию, а файлы используют все ;)
P.S.: Вспоминая старые советские учебники по информатике припоминаю что-то такое, думаю, можно найти ГОСТ с описанием сущности «файл в информационной системе».
Конечность, строго говоря, не обязательна: \ dev\null тому пример. И вы правильно определили основные структуры, присущие файлу, как математическому объекту.
Таки "в основном — чёткие правила, но иногда — исключения" всё равно лучше, чем "пиши как хочешь; есть, конечно, пара правил, но и их нужно воспринимать скорее как правила хорошего тона, а не жёсткий канон".
Это называется проблема поиска денотационной семантики. Работа в этом направлении идёт и далека от завершения. Для многих это жуть жуткая и муть мутная, каждый день не нужная. Но для тех кто пишет компиляторы и верификаторы это крутой инструмент.
А файл (POSIX) можно отождествить с анаморфизмом, порождающим свободный моноид, его обработчики — с гиломорфизмами. Файловая система — дерево, или более общий граф, если она реляционная и т.п. Мы используем эти понятия, не зная, что "говорим прозой".
И хотел бы добавить, современная математика огромна. Не торопитесь судить о ней в терминах "никакая математика не определит"… Например, о трех табуретках: теория устойчивости, даже линейная удовлетворительно отличит одно применение от другого.
И хотел бы добавить, современная математика огромна. Не торопитесь судить о ней в терминах «никакая математика не определит»…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
Можно сделать мат. модель файла, но мы столкнемся с ограничениями моделирования, о которых в статье.
Вот именно. Что характерно, все чаще именно в документации к прикладным библиотекам появляется отдельная главка с денотационной семантикой ее вызовов. И у тех, у кого она есть, обычно все работает круто и продуманно.
Кстати, насчет паттернов. Складывается впечатление, что ООП — есть суть, набор паттернов. Т.е. некие согласованные правила написания кода. Думаю, паттерны и были порождены тем самым множеством вариантов использования в ООП. И люди, пытаются упростить себе жизнь.
Чем больше я писал код в ООП, тем чаще выдумывал паттерны. Честно говоря, устал — надоело! Слез с ООП в итоге в пользу декларативных подходов и простоты Go.
Аналогично, только ушел на Rust и часто пользуюсь функциональным подходом в нем. Rust — потому что я на C++ писал много низкоуровневых оптимизаций, со ссылками на стек и т.д., чтобы без счета ссылок и без сборки мусора, а именно на compile-time, и на Rust это как раз очень хорошо ложится. Go смотрел, хороший язык, но совсем не для моих задач.
В конце прошлого века всемирно известные люди Билл Гейтс, Филипп Кан, Бьёрн Страуструп, Никлаус Вирт и др., не желая того, заложили бомбу под ООП, слишком восторженно его пропагандируя.Не мог бы автор статьи рассказать, где, когда и как именно Вирт пропагандировал ООП? Ни в одном из языков, созданных Виртом, нет классов, объектов и наследования. Вирт (и позаимствовавший идеи Вирта язык Go) пропогандирует компонентный подход (альтернативный ООП, построенному на наследовании), являющийся очень простым расширением классического процедурного програмирования.
Скорее наоборот, ООП — мод компонентно-ориентированного программирования...
JavaScript — не имеет классов и инкапсуляции (впрочем, недавно в JS добавили пародию
на классы, но это только синтаксический сахар). Это ООП?
Полиморфизм? Так он прекрасно реализуется в любом языке, поддерживающем ссылки на подпрограммы — безо всякого ООП.
Так что такое ООП? И как может быть ООП в языке, не имеющем объектов? Может быть, стоит дать определение ООП — прежде чем смешивать мух и котлет?
Oberon не имеет классов, объектов и наследования. Это ООП?Сужу по Вики (я только читал про Oberon, но ничего на нем не писал):
Инкапсуляция поддерживается исключительно на уровне модуля — все типы, объявленные внутри модуля, друг для друга абсолютно прозрачны. Из других модулей доступно то, что объявлено при определении как экспортируемое.
Полиморфизм обеспечивается за счёт механизма методов (и процедурные поля в Обероне, и методы в Обероне-2 ведут себя как виртуальные, в терминологии большинства гибридных объектно-ориентированных языков), а также расширенной конструкцией WITH, позволяющей выполнять различные группы операторов в зависимости от того, к какому из расширенных типов относится её аргумент.
В языке отсутствует специальный механизм конструкторов. Рекомендуемым методом создания и инициализации объектов является описание порождающих модулей и процедур (в традиционной терминологии ООП — factory).
Программа в такой технологии представляет собой набор относительно самостоятельных компонентов (в данном случае — модулей), имеющих скрытую от внешнего мира внутреннюю структуру и чётко определённый интерфейс. Модули могут загружаться и выгружаться динамически, во время работы программы, система предоставляет развитые средства контроля типов во время выполнения, которые позволяют писать универсальные алгоритмы обработки данных, не зависящие от конкретных типов этих данных (например, библиотека для работы с СУБД может предоставлять методы, записывающие результат запроса из базы в запись произвольной структуры, если набор и типы полей этой записи соответствуют набору и типам полей в БД).
[...] Объектно-ориентированное программирование
Средства объектного программирования интерпретируются в Обероне как естественное развитие средств работы с записями в модульной системе, точнее, как технический инструментарий для решения конкретной архитектурной задачи: обеспечить эффективное «разделение труда» между различными модулями при работе с динамическими типами и структурами данных: например, работа с указателями в списке может быть скрыта (вместе с соответствующими полями) в одном модуле, а определение и работа с конкретным «наполнением» элементов списка — задаваться в другом (или, чаще, других). В этом смысле технология объектного программирования в Обероне подчинена концепции модульности: она здесь является, скорее, средством описания данных, чем средством построения архитектуры приложения в целом.
Так что такое ООП? И как может быть ООП в языке, не имеющем объектов?ООП — это стиль программирования. Его можно использовать хотя на ассемблере, реализовав всю поддерживающую инфраструктуру. ООП ориентированный язык уже содержит поддержку этого стиля.
Что касается высказываний апологетов функционального программирования в адрес ООП, то их аргументы могут выглядеть красиво в ряде ограниченных случаев, но как только дело доходит до реальных применений, где просто невозможно избежать наследования данных и множества композитов, то тут они просто тихо сливаются. Собственно, ООП не отвергает ФП, а просто использует его как часть общей идеологии. В отличие от.
Я не смог вспомнить ни одного такого примераЗначит просто не сталкивались. У меня задачи проектирования и моделирования запросто уходили на 5-6 уровней наследования и до нескольких десятков композитов (только на одном уровне, а с наследованием еще больше) — это просто отображение реальных объектов и процессов.
всё выливается в обычную композицию функцийХорошо, когда над объектом нужно выполнить одну-две операции, а когда их больше и нужно, кроме всего прочего, поддерживать/контролировать целостность, связанность и непротиворечивость данных, то ООП становится вне конкуренции, т.к. позволяет держать все в «одном месте», а при поддержке языка, еще ограничить стороннего программиста от желания «поковыряться внутри».
5-6 уровней наследования и до нескольких десятков композитов (только на одном уровне, а с наследованием еще больше) — это просто отображение реальных объектов и процессов.
Что есть отображение реальных процессов которые нельзя выразить без наследования? Мне в голову пока лишь квадрат с прямоугольником, да собака с млекопитающим и т.п. лезет, и в обоих случаях можно обойтись без наследования.
невозможно избежать наследования данных
…
Хорошо, когда над объектом нужно выполнить одну-две операции, а когда их больше и нужно, кроме всего прочего, поддерживать/контролировать целостность, связанность и непротиворечивость данных
Наследовнание данных это просто наследование структур, наследованием в ООП обычно называют наследование поведения, и действия производятся объектом, а не «над» объектом
ООП становится вне конкуренции, т.к. позволяет держать все в «одном месте»
Что и в каком месте, почему при композиции всё не в одном месте?
Если объект большой, может его вообще стоит декомпозировать на логические части с минимальной связностью без наследований и композиций?
Мне в голову пока лишь квадрат с прямоугольником, да собака с млекопитающим и т.п. лезетОписывать имеющуюся систему у меня нет возможности, но речь идет о поведенческих моделях, где на верхнем уровне абстракции имеются лишь самые общие свойства. На втором уровне появляются несколько конечных и несколько абстрактных объектов с новыми свойствами. Аналогично третий и четвертый уровни. Пятый и шестой уровни, в основном, описывает уже очень сложные композитные системы, которые, тем не менее, все еще прекрасно могут быть поняты функциями, работающими с предыдущими уровнями.
Причин сомневаться в ошибочности построенной модели нет, т.к. более чем десятилетняя ее эксплуатация не выявила каких-либо недостатков ни в процессах использования, ни в процессах расширения функционала.
почему при композиции всё не в одном местеКогда композиция является частью объекта, никаких проблем не возникает.
Можно пример-то?Ответил выше.
Ну так функции над каким-то (непрозрачным) типом данных вполне могут отслеживать все нужные вам инварианты.Функции, не имеющие доступа к данным, по определению могут отслеживать только часть целостности. Функции, которые имеют доступ к данным, могут реализовать все что нужно и называются методами объекта. Нет никакой необходимости отделять их от данных.
Держать всё в одном месте лучше с помощью модулей, и в языках с нормальной модульной системой делать это очень приятноНа счет модулей спорить не буду, равно как и утверждать, что жить без них нельзя.
Миф — ООП — это серебрянная пуля.
Правда — не каждому дано отлить
В приведенных книгах упомянуто много источников на тему моделирования, в том числе цитируется следующий пример. Если поставить 3 табуретки друг на друга, то эта конструкция будет вполне устойчивой, чтобы водрузить на нее бумажный кубик для школьного урока рисования. Но эта же конструкция явно неустойчива, чтобы с ее помощью поменять сгоревшую лампочку. Никакая математика сделать такие выводы не сможет.
Может. Теория автоматического управления. И даже несколькими способами оценки устойчивости.
По названию подумал что может расскажут для чего и как ООП появлялось, про messaging там и information hiding, но нет, в очередной раз нам что-то пытаются рассказывать про плюсы и минусы мифического инструмента X даже не рассказывая что это за инструмент, приправляя всё это сказами про наследование классов.
может расскажут для чего и как ООП появлялосьУ статьи нет пометки «Tutorial», т.о. предполагается, что читатель в достаточной степени владеет предметом — хотя бы в объеме статьи в Википедии.
нам что-то пытаются рассказывать про плюсы и минусы мифического инструмента X
См. статью — указаны реальные (не мифические) инструменты:
Буду исходить из умеренного простого подхода ОО Паскаля, заложенного еще в Turbo Pascal 5.5 и окончательно оформившегося к Delphi 7 (можно отметить и близкие по концепции ЯП других производителей, например, Think Pascal для MacOS).
даже не рассказывая что это за инструмент
Выше указал, что не «Tutorial». Про Object Pascal (Delphi и т.д..) надеюсь большинство читателей знает.
приправляя всё это сказами про наследование классов
А где конкретно сказки? ;)
Это не вопрос, а название вашей статьи.
Весь ваш «ответ» сводится к одному предложению — «ООП не решит все проблемы», даже не ваш ответ, а цитата из книжки. Это все что вы хотите донести до читателей? Больше никакой конкретики я не вижу.
> См. статью — указаны реальные (не мифические) инструменты:
Пока в статье используются термины не имеющие однозначной трактовки, и вы не даёте ее в контексте этой статьи, ни о каких конкретных инструментах речи не идёт.
Если статья о наследовании — напишите что статья о наследовании. Причем тут ООП? Я вот ОО-код без наследования пишу.
> хотя бы в объеме статьи в Википедии
Википедия во первых не источник правды, во вторых также однозначной трактовки не даёт.
> Выше указал, что не «Tutorial». Про Object Pascal (Delphi и т.д..) надеюсь большинство читателей знает.
То есть статья не про парадигмы а про ЯП? Кто-то ещё пишет проекты на Паскале?
Весь ваш ответ сводится к одному предложениюНе сводится, а Вы его сводите.
Больше никакой конкретики я не вижу.Смотрите внимательнее. В самом начале я указал 3 недавних статьи, высказывающие противоположные мнения на данную тему. Это не конкретика? Далее привел «показательный типичный комментарий» и т.д. Что м.б. конкретнее? Вы даже в начале этой конкретики не увидели, поэтому возникает закономерный вопрос: статью читали?
Пока в статье используются термины не имеющие однозначной трактовкиКак такое возможно?: в конкретном ЯП, нпр., Delphi 7 важный термин, нпр., наследование не имеет однозначной трактовки? — Явный абсурд!
Далее у Вас не менее абсурдное заявление:
Википедия во первых не источник правдыКто Вам это сказал? К Вашему сведению Вики делают (пишут, редактируют, обсуждают) в том числе много очень грамотных людей, в том числе спецы мирового уровня. Все, что скзано в вики, должно быть подкреплено ссылками на авторитетные источники. Если что-то ситуативно не подкреплено, то будет подкреплено или будет удалено в ближайшее время.
во вторых также однозначной трактовки не даёт.Подымите первоисточник. Где в указанной статье вики неоднозначные трактовки терминов, которые в моей статье? Вы пытаетесь обвинять меня в отсутвии конкретики, но сами предельно неконкретны, поэтому все Ваши обвинения звучат голословно и бездоказательно.
Кто-то ещё пишет проекты на Паскале?Много кто пишет. Поиск на Хабре и Гугл Вам в помощь :) Сами какой ЯП знаете? После Ваших заявлений возникает подозрение, что Ваш кругозор дальше одного языка не простирается.
Я читал предыдущие статьи, но в данном случае о них речи не идёт. Мне интересно что же вы хотите донести этой статьей, и в этой статье никакой конкретики я не вижу.
> Как такое возможно?: в конкретном ЯП, нпр., Delphi 7 важный термин, нпр., наследование не имеет однозначной трактовки? — Явный абсурд!
Пока не понятно каким образом статья связана с ООП, и этого термина трактовку вы не привели. Единственный «миф» который вы пока что развеяли — что не существует в данном случае серебряной пули, только, не ново это уже давно.
Вопросы про мой кругозор, пожалуй, оставлю за кадром.
Вопросы про мой кругозор пожалуй оставлю за кадром.
Ответ на этот вопрос м.б. много объяснит. Почему Вы считаетет, что можете не отвечать на мой закономерно возникший вопрос, но требуете ответы у меня на совершенно надуманные вопросы?
трактовку этого термина вы не привелиЯ не обязан приводить трактовку — я привел ссылки на инструменты, где реализованы похожие трактовки и этого достаточно. У меня, нпр., есть «координаты точки» — потребуйте еще трактовку этого термина и, заодно, термина «програмирование» ;))
этой статье никакой конкретики я не вижу.У Вас, видимо, своеобразное понимание конкретики, если в 4 статьях с большими просмотрами и обсуждениями не увидели конкретики, то помочь Вам не смогу.
Хотя и в предыдущих ее не сильно много то. Так, в комментиках поспорить.
в этой статье никакой конкретики я не вижу.
У Вас, видимо, своеобразное понимание конкретики, если в 4 статьях с большими просмотрами и обсуждениями не увидели конкретики, то помочь Вам не смогу.
Вы серьёзно? Причем тут 4 статьи с просмотрами и обсуждениями? Конкретно сейчас действие происходит под одной, одной единственной статьёй, с id 453836, в комментариях под которой мы сейчас находимся, о каких-то других статьях речи не ведётся.
Я не обязан приводить трактовку — я привел ссылки на инструменты, где реализованы похожие трактовки и этого достаточно
Поэтому статья и бессмысленна. Единственный пример который вы привели — пример наследования. Всё. К термину «наследование» у меня претензий не было.
меня, нпр., есть «координаты точки» — потребуйте еще трактовку этого термина и, заодно, термина «програмирование» ;))
На википедии гляньте. Они там вполне однозначно описаны.
За сим не вижу смысла продолжать этот диалог и биться о барьер чьей-то психологическей защиты.
о каких-то других статьях речи не ведётсяКак не ведётся? — Вы написали:
Хотя и в предыдущих ее не сильно много то.
Поэтому статья и бессмысленна.
Просто убойный вывод!
Единственный пример который вы привели — пример наследования.+сказано: инкапсуляция, полиморфизм.
не вижу смысла продолжать этот диалогНе продолжайте.
.
Мифы и реальность ООП