Здравствуйте, grosborn, Вы писали:
G>http://msdn.microsoft.com/en-us/library/windows/desktop/dd183395(v=vs.85).aspx G>Brush Functions
G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП? И если это не процедурный подход, то как выглядит "настоящий" процедурный подход?
Все просто — тут есть абстракция Brush, описывающая , наследующие её абстракции SolidColorBrush, HatchBrush, PatternBrush со своими конструкторами.
Так же есть абстрактный deviceContext, который принимает в свои методы абстрактный brush и работает с ним полиморфным образом.
Чистый ООП.
G>И если это ООП, то навиг мы вообще на ООП переходили, почему не кодировали все в таком же стиле?
А ты на С++/Джаве точно так же и пишешь с точностью до синтаксиса.
Здравствуйте, grosborn, Вы писали:
G>Я собственно мейнстрим и обзначил, последовательность формулирования основных подходов. Ни симула ни лисп не меняют эту последовательность, процедурный стиль возник до симулы и лиспа (не в современном виде конечно).
Тот процедурный стиль в котором написан WinAPI и который мы тут обсуждаем называется структурное
программирование и возник позже и лиспа и даже ОО.
С тобой я частично согласен в том что не все ООП что на него похоже.
Правоверные ООП'щики все что содержится в ООП любят преподносить так как будто
все это придумано именно в ООП и обязательно является частью этого ООП, хотя это
не так, такие паттерны как инкапсуляция, полиморфизм намного более общие и применяются
в разных парадигмах.
> Увы, ты ни на один вопрос здесь прямо не ответил.
vdimas объявил, что весь ООП это "ничего нового", практически практически модульно-процедурный стиль.
Ты объявил, что весь Win API это ООП (то есть процедурный стиль это ООП).
Я объявил, что несмотря на общие аспекты в использовании и в реализации, это разные парадигмы и объединять их в одно понятие не надо.
И, о чудо, доказывать не обязан!
Вы вдвоем вполне можете схлопнуться и аннигилировать без моего участия.
Здравствуйте, grosborn, Вы писали:
>> Увы, ты ни на один вопрос здесь прямо не ответил.
G>vdimas объявил, что весь ООП это "ничего нового", практически практически модульно-процедурный стиль.
Я за ним такого не помню, но в принципе верно.
G>Ты объявил, что весь Win API это ООП (то есть процедурный стиль это ООП).
Ты так и не понял, что я объявил и с чем не согласен. Уверен, что тезис vdimas-а ты переврал точно так же.
G>Я объявил, что несмотря на общие аспекты в использовании и в реализации, это разные парадигмы и объединять их в одно понятие не надо. G>И, о чудо, доказывать не обязан!
Так ты ничего и не доказываешь, порешь бурду про слонов.
G>Вы вдвоем вполне можете схлопнуться и аннигилировать без моего участия.
Я не вижу разногласий с vdimas-ом по этому поводу. Зато вижу что ты самоустраняешься за неимением аргументов и нежеланием что-либо доказывать.
Вообще это нормально реализуется в высшей стадии процедурного программирования,
то есть структурное программирование + абстрактные типы данных и никакого ОО
Здравствуйте, FR, Вы писали:
FR>Правоверные ООП'щики все что содержится в ООП любят преподносить так как будто FR>все это придумано именно в ООП и обязательно является частью этого ООП, хотя это FR>не так, такие паттерны как инкапсуляция, полиморфизм намного более общие и применяются FR>в разных парадигмах.
Ага, остается только наследование. Последнее делится на наследование интерфейса и наследование реализации.
Интерфейсы нужны для полиморфизма (ad-hoc). Интерфейсы, по сути, являются аналогом классов типов Haskell, если добавить к ним требование определять инстансы в том же месте, что типы (при определении типа нужно сразу указать все интерфейсы, которые он реализует). Т.е. тоже не являются прерогативой ООП. Остается только наследование реализации. Которое в последнее время считают антипаттерном. ООП — антипаттерн?
P.S. Да, наследование реализации можно рассматривать как вид автоматической "копипасты". Ее можно делать средставми метапрограммирования.
Re[25]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, grosborn, Вы писали:
>> Увы, ты ни на один вопрос здесь прямо не ответил. G>vdimas объявил, что весь ООП это "ничего нового", практически практически модульно-процедурный стиль.
Я утверждал, что ООП/КОП выросло из модульного подхода.
Даже вот из недавнего: берем кодек Speex, имеющий "чистое процедурное АПИ". На самом деле это классичесский модуль с небольшим публичным интерфейсом и большой инкапсулированной функциональностью внутри. Экземпляр кодека — это классический черный ящик с недоступной клиенту структурой. Объект создается как-то так: speex_codec * speex_create(params), удаляется как-то так: speex_destroy(speex_codec *). (Точные сигнатуры открывать облом, но не в них суть). Ну и любая операция с черным ящиком как-то так: speex_decode(speex_codec *, dataIn, dataOut).
При том, что в зависимости от аргументов создаются принципиально разные экземпляры кодеков, имеющие как разную структуру таки пользующиеся разными алгоритмами — все они имеют одинаковое АПИ. Вот тебе пример процедурного АПИ для классического КОП как интерфейса и ООП как очевидной использовавшейся парадигме.
Ну и напоследок. Когда ООП еще не было столь популярно уже успел оформиться в модульном программировании некий стиль "хорошего тона" — в точности такой же, как я показал на примере Speex. Дело оставалось за малым — поддержать этот стиль в языках. Но от языковой поддержки ничего существенного не изменилось (кроме синтаксиса) для таких программ, написанных по правилам "хорошего тона" для модульного ПО.
G>Ты объявил, что весь Win API это ООП (то есть процедурный стиль это ООП).
Никто не говорил, что весь, но оконная система упоминалась. Драйвера тоже. Тут не зря SmallTalk упоминали, такая же механика.
G>Я объявил, что несмотря на общие аспекты в использовании и в реализации, это разные парадигмы и объединять их в одно понятие не надо.
Это общие слова ни о чем.
G>И, о чудо, доказывать не обязан!
Обязан. И все ждали что попытаешься, чтобы показать где именно ты не прав. Но ты сдрыснул.
G>Вы вдвоем вполне можете схлопнуться и аннигилировать без моего участия.
Здравствуйте, grosborn, Вы писали:
>> Согласен. Вас надули. >> Надули с "новизной" ООП и прочих ископаемых аспектов. G>Ты вообще о чем? Типа про отсутствие новизны при переходе от процедурного программирования со структурами данных к ООП стилю программирования? Это как бы "и там и там текст и буквы, значит в любой книге нет ничего нового"?
Простой вопрос. Разработано ли для WinAPI и подобных псевдообъектно-ориентированных систем что-нибудь вроде UML и каких-либо методологий? Если нет, то назвать WinAPI объектно-ориентированной системой нельзя. Пресловутые полиморфизм с инкапсуляцией и т.п. можно разглядеть в совершенно неожиданных местах. Но это не значит что все, где это можно разглядеть, разрабатывалось с объектно-ориентированной парадигмой в уме. Действительно, если шимпанзе ходит на двух ногах — это еще не повод называть шимпанзе человеком. Сервис ориентированная архитектура — это ООП или не ООП? Пока не сможете ткнуть пальцем в конкретную методологию реализации, все эти рассуждения, является ли WinAPI объектно-ориентированной системой или не является — полная аналогия с эпизодом "синкопа-не-синкопа" в одном известном фильме.
Здравствуйте, FR, Вы писали:
FR>Вообще это нормально реализуется в высшей стадии процедурного программирования, FR>то есть структурное программирование + абстрактные типы данных и никакого ОО
А как там с наследованием?
Re[26]: Язык ДРАКОН — новая идея в программировании
V>Ну и напоследок. Когда ООП еще не было столь популярно уже успел оформиться в модульном программировании некий стиль "хорошего тона" — в точности такой же, как я показал на примере Speex. Дело оставалось за малым — поддержать этот стиль в языках. Но от языковой поддержки ничего существенного не изменилось (кроме синтаксиса) для таких программ, написанных по правилам "хорошего тона" для модульного ПО.
Это структурное программирование + абстрактные типы данных + модульность.
И сформировалось оно все-таки пораньше чем мейнстримный сейчас (C++/C#/Java) ООП.
И это по моему не ООП, наследования нет и полиморфизм без виртуальных методов.
Здравствуйте, artelk, Вы писали:
A>P.S. Да, наследование реализации можно рассматривать как вид автоматической "копипасты". Ее можно делать средставми метапрограммирования.
Дык, так и оно есть. Именно копипасты.
Наследование реализации или любой другой способ использования готового кода (например, через библиотеки), по принципу использования стоит на одном уровне с макросами. В любом случае как цель идет повторное использование ранее написанного кода, а отличается лишь механика: использование имеющегося кода на этапе компиляции или на этапе линковки.
И да, макросы — это не обязательно метапрограммирование. Метапрограммирование чаще всего ставит целью адаптацию/расширение синтаксиса и затем использование существенно ДРУГОГО языка чем хостовый. Большинство же макросов на самом деле имеют сугубо библиотечный характер и писаны с той же целью, что библиотеки.
Здравствуйте, 0x7be, Вы писали:
FR>>Вообще это нормально реализуется в высшей стадии процедурного программирования, FR>>то есть структурное программирование + абстрактные типы данных и никакого ОО 0>А как там с наследованием?
FR>Вообще это нормально реализуется в высшей стадии процедурного программирования, FR>то есть структурное программирование + абстрактные типы данных и никакого ОО
Я всегда считал, что ООП зиждется на структурном программировании и отличается от него лишь встренной языковой поддержкой абстрактных типов данных (чтобы их не надо было эмулировать) и ничем более. Т.е. синтаксическим сахарком. ))
Здравствуйте, vdimas, Вы писали:
FR>>Вообще это нормально реализуется в высшей стадии процедурного программирования, FR>>то есть структурное программирование + абстрактные типы данных и никакого ОО V>Я всегда считал, что ООП зиждется на структурном программировании и отличается от него лишь встренной языковой поддержкой абстрактных типов данных (чтобы их не надо было эмулировать) и ничем более. Т.е. синтаксическим сахарком. ))
Ага, а современные машины отличаются от первых тарантасов наличием парктроника.
G>И сразу переврал. Это не object identifier, а внутренний идентификатор структур данных в ОС. Если бы это был object identifier, он так и назывался бы — object identifier. А он называется хэндл.
Хендл и есть object identity, о котором шла речь.
>> 2. Наличие полиморфизма. Смотрим, к примеру, сюда и обнаруживаем, что волшебные функции SelectObject и DeleteObject корректно работают со всеми видами кистей.
G>Есть еще более обобщающий пример — CloseHandle().
Дык, а у драйверов есть очередь сообщений или таблица ф-ий. Такая же точно таблица виртуальных ф-ий, только описанная явно.
Поэтому твой CloseHandle работает.
G>То есть то что одна единственная процедура освобождает разные структуры данных ОС по идентификатору, это ты считаешь ОО подоходом. То есть вообразил себе, что все (группы процедур со струтурами), это на самом деле не процедуры со структурами, а объекты. То есть тебе даже не важна внутренняя реализация, не важна нотация, не важна даже (!)группировка процедур в объект, просто назвал объектом и вуаля — ООП готово. G>Да я что, спорить не будут. Зато весело.
Весело от непонимания ОО-парадигмы, очевидно. Ты цепляешься исключительно за синтаксис, а ведь речь шла о торчащих из WinAPI ушей ОО-парадигмы.
И да, твоя группировка существует. При включении опции strict при компиляции исходников WinAPI ты далеко не везде сможешь использовать кисть вместо карандаша и наоборот, а только там, где это допустимо.
G>Я знаю как выглядит процедурное программирование, в отличие от некоторых.
Процедурное программирование выглядит очень по-разному. Без использования каких-либо популярных парадигм, в структурном программировании получается одно такое глобальное состояние. Тоже вполне работает на небольших задачах...
