> Согласен. Вас надули. > Надули с "новизной" ООП и прочих ископаемых аспектов.
Ты вообще о чем? Типа про отсутствие новизны при переходе от процедурного программирования со структурами данных к ООП стилю программирования? Это как бы "и там и там текст и буквы, значит в любой книге нет ничего нового"?
Здравствуйте, grosborn, Вы писали:
>> Надули с "новизной" ООП и прочих ископаемых аспектов. G>Ты вообще о чем? Типа про отсутствие новизны при переходе от процедурного программирования со структурами данных к ООП стилю программирования?
>>> Надули с "новизной" ООП и прочих ископаемых аспектов. > G>Ты вообще о чем? Типа про отсутствие новизны при переходе от процедурного программирования со структурами данных к ООП стилю программирования? > > Для тех, кто в танке: >
> ООП/КОП — развитие модулей,
Ага. Если глупость повторить два раза, она от этого умнее не станет. ООП ни разу не развитие модулей.
Здравствуйте, grosborn, Вы писали:
G>ООП ни разу не развитие модулей.
ООП — это концепция состояния как черного ящика. Эта концепция получила популярность и воплощение именно как модульность, ноги инкапсуляции растут оттуда.
И да, ООП не всегда означает ОО-язык. Например, Windows API — это самая настоящая ОО-концепция, включая инкапсуляцию, наследование и полиморфизм (см интерфейс общения с окнами или с драйверами устройств), хоть и сам АПИ оформлен в виде свободных ф-ий и подсистем (модулей). но такое оформление растет исключительно из-за требований нейтральности к языку. Сейчас это АПИ переписали полностю в ООП-виде (WinRT), не особо изменив семантику. ЧТД.
> G>ООП ни разу не развитие модулей. > > ООП — это концепция состояния как черного ящика. Эта концепция получила популярность и воплощение именно как модульность, ноги инкапсуляции растут оттуда. > > И да, ООП не всегда означает ОО-язык. Например, Windows API — это самая настоящая ОО-концепция, включая инкапсуляцию, наследование и полиморфизм (см интерфейс общения с окнами или с драйверами устройств), хоть и сам АПИ оформлен в виде свободных ф-ий и подсистем (модулей). но такое оформление растет исключительно из-за требований нейтральности к языку. Сейчас это АПИ переписали полностю в ООП-виде (WinRT), не особо изменив семантику. ЧТД.
Ты пытаешься как-то обосновать свое мнение. Не надо. Это ошибка и ты если подумаешь непредвзято сам поймешь это. ООП имеет ряд общих моментов с модульностью и на поверхностный взгляд, рассматривая только эти аспекты, может показаться что у них взаимоотношение наследственности. Но ООП это не только эти аспекты, это мегатонны всего чего нет и не могло появится в модульности. ООП это скорее шаг в сторону.
WinAPI это не ООП, это именно модульная идеология не ОО. Про наследование в Win API это ты конечно размечтался и тебя занесло.
Это две разных идеологии имеющие ряд общих аспектов.
Здравствуйте, grosborn, Вы писали:
G>WinAPI это не ООП, это именно модульная идеология не ОО.
Идеология интерфейса именно ОО. Попробуй дать определение ООП. Пойдет как исходное, так и "современное". API Windows удовлетворяет обоим.
G>Про наследование в Win API это ты конечно размечтался и тебя занесло.
Это принцип работы оконной подсистемы. Самое что ни на есть наследование поведения, инкапсуляция, полиморфизм. И даже непосредственная модель обмена сообщениями. Просто ты не в курсе, похоже.
G>Это две разных идеологии имеющие ряд общих аспектов.
Ты пытаешься доказывать, что Win API "самое настоящее ООП". Мне даже не смешно. Я хз где ты учился и учился ли вообще, что читал, откуда такие закидоны.
Здравствуйте, grosborn, Вы писали:
G>WinAPI это не ООП, это именно модульная идеология не ОО. Про наследование в Win API это ты конечно размечтался и тебя занесло.
Вообще говоря, можно и считать. Давно уже пришел к выводам, что WinAPI как раз вполне себе ООП. Окончательно меня осенило лет 12 назад, когда читал книжку по DirectX и как обращаться ко всему этому из Си. Киты ООП — абстрагирование, ограничение доступа, модульность, иерархичность, типизация, параллелизм, устойчивость. Проблема с этим в WinAPI наблюдается только с типизацией, здесь, увы, ничего не поделаешь. А с остальным — вполне все хорошо. Получили хендл — это эквивалентно оператору new. Даже с конструктуром. Далее мы этот хендл передаем в определенные методы. Внутренности у нас вполне себе инкапсулированы, мы ничего о них не знаем, общаемся через хендл. Одновременно разные части программы могут параллельно работать с разными хендлами — никаких пересечений не будет, друг на друга не аффектят и не перетирают. Хендл запросили в одном месте — он живет и после того, как мы вышли их метода, который запрашивал хендл, так что все устойчиво. С иерархичностью можно привести пример разные классы окон.
Уже давно понял, что практически на любом языке можно вполне сочетать различные парадигмы программирования, даже если язык под это изначально не предназначен. На ООП вполне можно писать в императивном и функциональном стиле, на императивном языке можно писать в ООП стиле (да, именно с типами проблема, можно словить неприятные ошибки).
Ну спасибо. Ну хоть бы промолчал. Или бы выразился корректно, что в Win API ты видишь элементы, которые были использованы и в ООП идеологии. Ну нет, ты даешь почву этому эээ... устроить тут дурацкий флейм.
Учите историю, что ле. Win API это это (не очень чистый конечно) процедурный подход. Сказать что это вполне себе ООП, это значит сказать что процедурного стиля, идеологии не было вовсе. Заложен был именно в процедурном стиле, но пока разрабатывался уже пошло развитие и пропагандирование ООП. DirectX вообще-то не Win API. Он появился значительно позже, когда ООП уже везде было, но его естественно писали в режиме совместимости с Win API.
Здравствуйте, grosborn, Вы писали:
G>Учите историю, что ле. Win API это это (не очень чистый конечно) процедурный подход. Сказать что это вполне себе ООП, это значит сказать что процедурного стиля, идеологии не было вовсе. Заложен был именно в процедурном стиле, но пока разрабатывался уже пошло развитие и пропагандирование ООП. DirectX вообще-то не Win API. Он появился значительно позже, когда ООП уже везде было, но его естественно писали в режиме совместимости с Win API.
Я уже аргументировал, почему там ООП. Там только типизации не хватает (а ее невозможно эмулировать на императивных языках без черти какого оверхеда), а очень многое там вполе ООП. С весьма небольшой натяжкой, ибо ООП там эмулировалось, а не было встроенным.
Историю вроде знаю неплохо, правда без дат, с датами всегда плохо было. Первые графические интерфейсы, появившиеся задолго даже до windows 1.0 были написаны на вполне ООП языке SmallTalk. Процедурный стиль был, и еще как был. Во времена до GUI. А именно развитие GUI дало почву для развития ООП языков и ООП вообще. Естественно я далек от того, чтобы говорить, что весь WinAPI написан в ООП стиле. Но элементы ООП там вполне присутствуют. ООП — это именно объектно ориентированный подход. Он применим на абсолютно любом языке, хоть на ассемблере. Естественно он довольно хреново записывается на императивных языках, и писать в таком стиле удовольствия весьма небольшое. Естественно никто в здравом уме не стал бы писать Windows на тормозных тогдашних ООП языках, учитывая тогдашнее железо. Написать весьма серьезный GUI, с обменом сообщений, целиком используя процедурный подход — крайне проблематично. А авторы даже первой винды про ООП достаточно хорошо знали. Естественно, что первые программы под нее писали в процедурном стиле, и они использующими ООП не были ни разу.
На основании того, что ходит на двух ногах, ты шимпанзе называешь человеком. Хендл со структурами данных не ООП, так же как шимпанзе не человек. Хотя они оба приматы. Я не знаю как тебе это объяснить, но вещи нужно называть своими именами.
Win API не ООП, епть.
Здравствуйте, grosborn, Вы писали:
G>На основании того, что ходит на двух ногах, ты шимпанзе называешь человеком. Хендл со структурами данных не ООП, так же как шимпанзе не человек. Хотя они оба приматы. Я не знаю как тебе это объяснить, но вещи нужно называть своими именами. G>Win API не ООП, епть.
> G>На основании того, что ходит на двух ногах, ты шимпанзе называешь человеком. Хендл со структурами данных не ООП, так же как шимпанзе не человек. Хотя они оба приматы. Я не знаю как тебе это объяснить, но вещи нужно называть своими именами. > G>Win API не ООП, епть. > > А если подойти формально, а не по понятиям?
По понятиям это не ко мне (приветики твоей религиозной вере в википедию). Всегда стараюсь соответствовать формальной логике.
Здравствуйте, grosborn, Вы писали:
>> G>На основании того, что ходит на двух ногах, ты шимпанзе называешь человеком. Хендл со структурами данных не ООП, так же как шимпанзе не человек. Хотя они оба приматы. Я не знаю как тебе это объяснить, но вещи нужно называть своими именами. >> G>Win API не ООП, епть. >> >> А если подойти формально, а не по понятиям?
G>По понятиям это не ко мне (приветики твоей религиозной вере в википедию). Всегда стараюсь соответствовать формальной логике.
Логику нужно применять, а не стараться соответствовать ей (приветики твоей религиозной вере в дурацкие аналогии типа шимпанзе). Если не знаешь, как объяснить, начни с простого. Выпиши формальные признаки объектно-ориентированной системы, проверь их наличие в WinAPI.
> Логику нужно применять, а не стараться соответствовать ей (приветики твоей религиозной вере в дурацкие аналогии типа шимпанзе). Если не знаешь, как объяснить, начни с простого. Выпиши формальные признаки объектно-ориентированной системы, проверь их наличие в WinAPI.
Ты чего пытаешься меня учить? Не то что бы я совсем против замечаний, но это же у тебя с логичностью суждений всегда проблемы. Даже в этом твоем посте несколько ошибок и проявление узости мышления (кроме формальных признаков есть еще и исторически сложившиеся использования понятий).
Здравствуйте, grosborn, Вы писали:
>> Логику нужно применять, а не стараться соответствовать ей (приветики твоей религиозной вере в дурацкие аналогии типа шимпанзе). Если не знаешь, как объяснить, начни с простого. Выпиши формальные признаки объектно-ориентированной системы, проверь их наличие в WinAPI.
G>Ты чего пытаешься меня учить? Не то что бы я совсем против замечаний,
Ты написал, что не знаешь как объяснить. Я тебе написал, с чего начать. Если бы ты сделал как я сказал, нужда в объяснении заблуждений отпала бы.
G>но это же у тебя с логичностью суждений всегда проблемы.
Можно конкретнее?
G> Даже в этом твоем посте несколько ошибок и проявление узости мышления (кроме формальных признаков есть еще и исторически сложившиеся использования понятий).
По-моему узость как раз демонстрируешь ты. Если копнуть историю, то станет очевидно что объектно-ориентированное программирование и программирование на объектно-ориентированных языках это не одно и тоже. А раз так, то из того что WinAPI писалось не на Java, не следует что WinAPI не объектно-ориентировано.
Здравствуйте, grosborn, Вы писали:
G>Ты пытаешься доказывать, что Win API "самое настоящее ООП". Мне даже не смешно.
Просто я хорошо его знаю и много под него программировал когда-то. Даже если пользовать голый С для программирования окошек, всё равно получается ООП в случае применения техники рефлексии сообщений источнику.
G>Я хз где ты учился и учился ли вообще, что читал, откуда такие закидоны.
Ладно. Это уже 2-я подветка, где ты не можешь связать 2-х слов, т.е. привести хоть одно возражение по-существу. Тут невооруженным взглядом видно, что ты не в состоянии отличить ОО-язык от ОО-парадигмы, просто я расчитывал показать это на конкретике... Видно, не судьба... Ты WinAPI в глаза не видел и вряд ли уже увидишь. (судя по твоей реакции на банальные, в общем-то, вещи)
Здравствуйте, elmal, Вы писали:
E>Проблема с этим в WinAPI наблюдается только с типизацией, здесь, увы, ничего не поделаешь. А с остальным — вполне все хорошо.
Дык, ООП не требует никакой типизации для своей работы. См. SmallTalk.
Типизация — это малость ортогональная характеристика.
E>Получили хендл — это эквивалентно оператору new. Даже с конструктуром. Далее мы этот хендл передаем в определенные методы. Внутренности у нас вполне себе инкапсулированы, мы ничего о них не знаем, общаемся через хендл. Одновременно разные части программы могут параллельно работать с разными хендлами — никаких пересечений не будет, друг на друга не аффектят и не перетирают. Хендл запросили в одном месте — он живет и после того, как мы вышли их метода, который запрашивал хендл, так что все устойчиво. С иерархичностью можно привести пример разные классы окон.
Угу, сабклассинг окон, где мы подменяем только часть функциональности предка. Такой сабклассинг может быть сколь угодно вложенным. Ну и полиморфизм в оконной системе или в системе драйверов устройств вшит в саму спецификацию WinAPI. Техника полиморфизма построена на отсылке предопределенных сообщений, независимо от экземпляра обработчика.
Здравствуйте, grosborn, Вы писали:
G>Хендл со структурами данных не ООП, так же как шимпанзе не человек. Хотя они оба приматы. Я не знаю как тебе это объяснить, но вещи нужно называть своими именами. G>Win API не ООП, епть.
> Если копнуть историю, то станет очевидно что объектно-ориентированное программирование и программирование на объектно-ориентированных языках это не одно и тоже. А раз так, то из того что WinAPI писалось не на Java, не следует что WinAPI не объектно-ориентировано.
Тяжело читать твои посты, полны нелогичности и непонятных выводов.
Вот опять это вот высказывание. Но ведь я не делал таких выводов, что стиль программирования и язык жестко связаны. "если C, то не ООП", это же ведь твое предположение, которое почему-то ты же и опровергаешь.
Но предположим, это была просто фигура речи, а если отбросить фантазии, за этой фигурой речи в десятый раз повторяется утверждение, что Win API это ООП подход, но написаный в процедурном стиле со структурами.
Я не понимаю. Мне конечно лень как-то обосновывать просто свое мнение. Ну предположим, ты об этом попросил.
Ну вот был процедурный стиль со структурами. Назывался он процедурным стилем. Возьмем какой-нибудь первый попавшийся пример. Выбираю случайный пример.
Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП? И если это не процедурный подход, то как выглядит "настоящий" процедурный подход?
И если это ООП, то навиг мы вообще на ООП переходили, почему не кодировали все в таком же стиле?
Здравствуйте, grosborn, Вы писали:
G>http://msdn.microsoft.com/en-us/library/windows/desktop/dd183395(v=vs.85).aspx G>Brush Functions
G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП? И если это не процедурный подход, то как выглядит "настоящий" процедурный подход? G>И если это ООП, то навиг мы вообще на ООП переходили, почему не кодировали все в таком же стиле?
С чего ты взял? Где там ООП? И окна тоже изначально процедурный подход. Изначально все API писали в этом стиле, а ООП использовать начинали на прикладном уровне.
Это процедурный подход потом перепевали при создании ООП попутно сильно изменив методологию и сильно дополнив, а не наоборот.
И, извините, земля круглая и вертится вокруг солнца, а не наоборот. И слонов с черепахами там не было, если что.
G>С чего ты взял? Где там ООП? И окна тоже изначально процедурный подход. Изначально все API писали в этом стиле, а ООП использовать начинали на прикладном уровне.
Там нет ООП, но ОО в стиле Алана Кея в полный рост.
Классы, сообщения, наследование все есть. Тот кто это писал явно видел Smaltallk.
G>Это процедурный подход потом перепевали при создании ООП попутно сильно изменив методологию и сильно дополнив, а не наоборот.
Тут концов не найдешь, современный хороший процедурный подход (структурное программирование Дейкстры) появился
в 70-ые годы, а ОО в виде симулы это 1967 год, так что постарше даже чуть.
G>И, извините, земля круглая и вертится вокруг солнца, а не наоборот. И слонов с черепахами там не было, если что.
Здравствуйте, grosborn, Вы писали:
G>Тяжело читать твои посты, полны нелогичности и непонятных выводов. G>Вот опять это вот высказывание. Но ведь я не делал таких выводов, что стиль программирования и язык жестко связаны. "если C, то не ООП", это же ведь твое предположение, которое почему-то ты же и опровергаешь.
Что опять? На нелогичность до этого ты мне так и не указал. Да и эта "нелогичность" куда логичнее твоего отсыла к обезьянам и истории без каких-то конкретных исторических фактов. Извини, я придумал причину, по которой ты считаешь WinAPI не OOP, за тебя. Навеяло твоей отсылкой к истории. Если у тебя другая причина, то ты таки укажи ее, что бы мне опять не домысливать.
G>Но предположим, это была просто фигура речи, а если отбросить фантазии, за этой фигурой речи в десятый раз повторяется утверждение, что Win API это ООП подход, но написаный в процедурном стиле со структурами.
Твоя интерпретация утверждения весьма далека от его смысла. Винапи демонстрирует все формальные черты ООП, выявленные Пирсом с коллегами. На чем он и с помощью чего написан — не суть важно, т.к. инструмент не является определяющим фактором.
G>Я не понимаю. Мне конечно лень как-то обосновывать просто свое мнение. Ну предположим, ты об этом попросил. G>Ну вот был процедурный стиль со структурами. Назывался он процедурным стилем. Возьмем какой-нибудь первый попавшийся пример. Выбираю случайный пример.
Ты не понимаешь, это я понял. То что тебе лень обосновывать свое мнение — тоже. И давай допустим что я об этом действительно попросил.
G>http://msdn.microsoft.com/en-us/library/windows/desktop/dd183395(v=vs.85).aspx G>Brush Functions
G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП? И если это не процедурный подход, то как выглядит "настоящий" процедурный подход? G>И если это ООП, то навиг мы вообще на ООП переходили, почему не кодировали все в таком же стиле?
Вот что интересно... Разве ты объясняешь свое мнение (как я тебя будто бы попросил)? Вместо этого ты опять спрашиваешь мое. Это ты называешь "логичностью"?
Но я все равно отвечу, предположив, что ты действительно меня спросил.
G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП?
Наличие формальных признаков ООП. G>И если это не процедурный подход, то как выглядит "настоящий" процедурный подход?
Примерно так же, только в нем нет значительной части признаков ООП.
G>И если это ООП, то навиг мы вообще на ООП переходили, почему не кодировали все в таком же стиле?
Так это и есть ООП. О переходе на какое еще ООП с этого ООП ты говоришь?
Почему не кодировали — ну так это к тебе вопрос. Многие до сих пор кодируют в таком стиле, придерживаясь при этом ООП практик. В то время как другие кодируют процедурно на ООП языках.
Ответь теперь, что тебя заставляет утверждать что это именно процедурный подход, а не ООП? Ответ за тебя я уже придумал и посмеялся над ним, но для интереса пока его не буду вбивать. Вполне возможно что я и не угадал.
> Тут концов не найдешь, современный хороший процедурный подход (структурное программирование Дейкстры) появился
Как это не найдешь концов? Вы действительно хотите переписать историю по данным википедии. История гибнет под напором самиусов. Все ходы записаны — коды->ассемблеры->процедурные языки-ООП. Оно не параллельно развивалось, а последовательно.
Здравствуйте, grosborn, Вы писали:
>> Тут концов не найдешь, современный хороший процедурный подход (структурное программирование Дейкстры) появился
G>Как это не найдешь концов? Вы действительно хотите переписать историю по данным википедии. История гибнет под напором самиусов. Все ходы записаны — коды->ассемблеры->процедурные языки-ООП. Оно не параллельно развивалось, а последовательно.
Вот видишь, моя догадка о том что ты языки связываешь с подходом была все-таки верна. Ты сам в этом расписался.
Re[20]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, grosborn, Вы писали:
>> Вот видишь, моя догадка о том что ты языки связываешь с подходом была все-таки верна. Ты сам в этом расписался.
G>Капец. ООП уже язык? Оо-о-о... помираю.... Даже аналогию с обезъянами ты так и не понял.
Я понял что ожидать от тебя аргументов другого уровня не стоит.
Здравствуйте, grosborn, Вы писали: G>http://msdn.microsoft.com/en-us/library/windows/desktop/dd183395(v=vs.85).aspx G>Brush Functions
Прекрасный пример. G>Что заставляет тебя утверждать, что это НЕ процедурный подход, а ООП?
1. Непрозрачность HBRUSH. Это не структура, а object identifier.
2. Наличие полиморфизма. Смотрим, к примеру, сюда и обнаруживаем, что волшебные функции SelectObject и DeleteObject корректно работают со всеми видами кистей.
Если вас интересует, как выглядит просто процедурное программирование, ознакомьтесь со старым C RTL с его FILE*
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Язык ДРАКОН — новая идея в программировании
>>> Вот видишь, моя догадка о том что ты языки связываешь с подходом была все-таки верна. Ты сам в этом расписался. > > G>Капец. ООП уже язык? Оо-о-о... помираю.... Даже аналогию с обезъянами ты так и не понял. > Я понял что ожидать от тебя аргументов другого уровня не стоит.
??? Ты думаешь я обязан доказывать неверность твоих предположений? Я никогда не связывал языки и парадигмы, это твои личные заблуждения, разбирайся со своими личными проблемами сам. Нормальный человек просто спросил бы меня и получил бы честный ответ, а твой путь настоящего джедая не принесет тебе ни чуть знаний.
Posted via RSDN NNTP Server 2.1 beta
Забанен на рсдн за применение слова "Маргинал"
Re[23]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, grosborn, Вы писали:
>> Я понял что ожидать от тебя аргументов другого уровня не стоит.
G>??? Ты думаешь я обязан доказывать неверность твоих предположений? Я никогда не связывал языки и парадигмы, это твои личные заблуждения, разбирайся со своими личными проблемами сам. Нормальный человек просто спросил бы меня и получил бы честный ответ, а твой путь настоящего джедая не принесет тебе ни чуть знаний.
Здравствуйте, grosborn, Вы писали:
>> Тут концов не найдешь, современный хороший процедурный подход (структурное программирование Дейкстры) появился
G>Как это не найдешь концов? Вы действительно хотите переписать историю по данным википедии. История гибнет под напором самиусов. Все ходы записаны — коды->ассемблеры->процедурные языки-ООП. Оно не параллельно развивалось, а последовательно.
То есть симулы не было?
История очень далека была от линейной, про lisp ты тоже забыл, пролог не существовал?
Линейная она как раз у победителей то есть структурного подхода и мейнстримного сейчас ООП.
Здравствуйте, grosborn, Вы писали:
G>WinAPI это не ООП, это именно модульная идеология не ОО. Про наследование в Win API это ты конечно размечтался и тебя занесло.
WinAPI — это объектно-ориентированный API, выраженный при помощи процедурного языка.
Что такое ООП? Чёткого определения нет, но обычно упоминают "три главных слова": инкапсуляция, наследование, полиморфизм.
Давай посмотрим на пример из WinAPI — GDI:
Там есть инкапсуляция — все детали реализации функций скрыты за непрозрачными device-handle`ами.
Там есть наследование и полиморфизм: существует много разных реализаций абстракции "устройство" — окно, принтер, растр в памяти, WMF и даже поверхность DirctDraw.
Со всеми ты работаешь единым образом (в терминах ООП это бы звучало как "через интерфейс базового класса device"), но конкретная реализация метода относится к конкретному типу устройства. Итак, мы видим все три основополагающих принципа ООП.
Ты, видимо, считаешь, что раз нет привычного синтаксиса: ключевого слова "class", "new", оператора "." и т.п., то нет и ООП.
Это не так.
А вот и штатный форумный тролль подтянулся. Здравствуйте.
> 1. Непрозрачность HBRUSH. Это не структура, а object identifier.
И сразу переврал. Это не object identifier, а внутренний идентификатор структур данных в ОС. Если бы это был object identifier, он так и назывался бы — object identifier. А он называется хэндл.
> 2. Наличие полиморфизма. Смотрим, к примеру, сюда и обнаруживаем, что волшебные функции SelectObject и DeleteObject корректно работают со всеми видами кистей.
Есть еще более обобщающий пример — CloseHandle().
То есть то что одна единственная процедура освобождает разные структуры данных ОС по идентификатору, это ты считаешь ОО подоходом. То есть вообразил себе, что все (группы процедур со струтурами), это на самом деле не процедуры со структурами, а объекты. То есть тебе даже не важна внутренняя реализация, не важна нотация, не важна даже (!)группировка процедур в объект, просто назвал объектом и вуаля — ООП готово.
Да я что, спорить не будут. Зато весело.
> Если вас интересует, как выглядит просто процедурное программирование, ознакомьтесь
Я знаю как выглядит процедурное программирование, в отличие от некоторых. Ты привел пример аналогичный моему, за исключением того, что это обертка функций Win API.
> То есть симулы не было? > История очень далека была от линейной, про lisp ты тоже забыл, пролог не существовал? > > Линейная она как раз у победителей то есть структурного подхода и мейнстримного сейчас ООП.
Я собственно мейнстрим и обзначил, последовательность формулирования основных подходов. Ни симула ни лисп не меняют эту последовательность, процедурный стиль возник до симулы и лиспа (не в современном виде конечно).
Здравствуйте, Sinclair, Вы писали:
S>1. Непрозрачность HBRUSH. Это не структура, а object identifier.
Ну инкапсуляция это общий паттерн.
S>2. Наличие полиморфизма. Смотрим, к примеру, сюда и
обнаруживаем, что волшебные функции SelectObject и DeleteObject корректно работают со всеми видами кистей.
Полиморфизм тоже.
S>Если вас интересует, как выглядит просто процедурное программирование, ознакомьтесь со старым C RTL с его FILE*
FILE * же по стандарту не прозрачный, и может выводить на разные устройства.
Здравствуйте, 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>Я знаю как выглядит процедурное программирование, в отличие от некоторых.
Процедурное программирование выглядит очень по-разному. Без использования каких-либо популярных парадигм, в структурном программировании получается одно такое глобальное состояние. Тоже вполне работает на небольших задачах...
Здравствуйте, vdimas, Вы писали:
V>Процедурное программирование выглядит очень по-разному. Без использования каких-либо популярных парадигм, в структурном программировании получается одно такое глобальное состояние. Тоже вполне работает на небольших задачах...
А парадигма состояния и кода, состояние это изменяющего, — это парадигма ООП или концепция из другой парадигмы в ООП украденная?
Здравствуйте, FR, Вы писали:
FR>Его нет. FR>И тут я его тоже не вижу.
Ну, вообще тут напрашивается абстрактный класс Brush и наследники — hatch, solid, pattern.
Хотя, то же самое может быть достигнуто полиморфизмом.
Re[25]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, grosborn, Вы писали:
G>Вы вдвоем вполне можете схлопнуться и аннигилировать без моего участия.
Но ты и правда не привел ни одного нормального аргумента.
Я прочитал Ваш спор — с твоей стороны исключительно эмоции в стиле "ну туп-ы-ы-ые!" и все.
Re[27]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, vdimas, Вы писали:
V>>Ну и напоследок. Когда ООП еще не было столь популярно уже успел оформиться в модульном программировании некий стиль "хорошего тона" — в точности такой же, как я показал на примере Speex. Дело оставалось за малым — поддержать этот стиль в языках. Но от языковой поддержки ничего существенного не изменилось (кроме синтаксиса) для таких программ, написанных по правилам "хорошего тона" для модульного ПО.
FR>Это структурное программирование + абстрактные типы данных + модульность. FR>И сформировалось оно все-таки пораньше чем мейнстримный сейчас (C++/C#/Java) ООП. FR>И это по моему не ООП, наследования нет и полиморфизм без виртуальных методов.
В минимальном наборе фич Пирса и К указана альтренатива наследованию — делегирование. А виртуальные методы там вообще не значатся. Это лишь инструмент для диспетчеризации, которая возможна и без них. Т.е. наследование и виртуальные методы не являются обязательными фичами ООП.
Здравствуйте, 0x7be, Вы писали:
FR>>И тут я его тоже не вижу.
0>Ну, вообще тут напрашивается абстрактный класс Brush и наследники — hatch, solid, pattern.
А это уже замыленный ООП взгляд
А я могу сказать что вижу размазанный алгебраический тип данных
type brush = Hatch | Solid | Pattern
и это эмуляция ФП
0>Хотя, то же самое может быть достигнуто полиморфизмом.
Там и так полиморфизм.
Re[28]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, samius, Вы писали:
FR>>Это структурное программирование + абстрактные типы данных + модульность. FR>>И сформировалось оно все-таки пораньше чем мейнстримный сейчас (C++/C#/Java) ООП. FR>>И это по моему не ООП, наследования нет и полиморфизм без виртуальных методов. S>В минимальном наборе фич Пирса и К указана альтренатива наследованию — делегирование. А виртуальные методы там вообще не значатся. Это лишь инструмент для диспетчеризации, которая возможна и без них. Т.е. наследование и виртуальные методы не являются обязательными фичами ООП.
Я про мейнстримный ооп.
Но даже без этого делегирования что-то не видно в тех же Brush Functions например.
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
S>>Если вас интересует, как выглядит просто процедурное программирование, ознакомьтесь со старым C RTL с его FILE*
A>За FILE* может скрываться, например, pipe. Т.е. тут тоже полиморфизм.
Так вроде будет скрываться на уровне ОС? Файловый int/handle и скрывает.
Здравствуйте, FR, Вы писали:
FR>А это уже замыленный ООП взгляд
А то!
FR>А я могу сказать что вижу размазанный алгебраический тип данных
А это уже замыленный функциональный взгляд
Здравствуйте, Fortnum, Вы писали:
F>Здравствуйте, grosborn, Вы писали:
>>> Согласен. Вас надули. >>> Надули с "новизной" ООП и прочих ископаемых аспектов. G>>Ты вообще о чем? Типа про отсутствие новизны при переходе от процедурного программирования со структурами данных к ООП стилю программирования? Это как бы "и там и там текст и буквы, значит в любой книге нет ничего нового"?
F>Простой вопрос. Разработано ли для WinAPI и подобных псевдообъектно-ориентированных систем что-нибудь вроде UML и каких-либо методологий? Если нет, то назвать WinAPI объектно-ориентированной системой нельзя. Пресловутые полиморфизм с инкапсуляцией и т.п. можно разглядеть в совершенно неожиданных местах. Но это не значит что все, где это можно разглядеть, разрабатывалось с объектно-ориентированной парадигмой в уме. Действительно, если шимпанзе ходит на двух ногах — это еще не повод называть шимпанзе человеком. Сервис ориентированная архитектура — это ООП или не ООП? Пока не сможете ткнуть пальцем в конкретную методологию реализации, все эти рассуждения, является ли WinAPI объектно-ориентированной системой или не является — полная аналогия с эпизодом "синкопа-не-синкопа" в одном известном фильме.
Как минимум обратное тоже не верно. Нельзя однозначно утверждать, что WinAPI не является ООП подходом.
А насчет UML — ДА, разработано. Вы забыли, что UML это не только модель классов.
Re[29]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, samius, Вы писали:
S>>В минимальном наборе фич Пирса и К указана альтренатива наследованию — делегирование. А виртуальные методы там вообще не значатся. Это лишь инструмент для диспетчеризации, которая возможна и без них. Т.е. наследование и виртуальные методы не являются обязательными фичами ООП.
FR>Я про мейнстримный ооп. FR>Но даже без этого делегирования что-то не видно в тех же Brush Functions например.
Так делегирование ведь не должно торчать из каждой строчки. В WinAPI оно в наличии. А конкретно в Brush Functions — можно лишь догадываться. Реализацию я не видел. Вполне возможно что оно реализовано с помощью делегирования, а может за C-style фасадом скрывается реализация всамделешными классами C++ и наследованием. Если и нет, то оно могло бы быть таким в Вынь10.
Здравствуйте, 11molniev, Вы писали:
F>>Простой вопрос. Разработано ли для WinAPI и подобных псевдообъектно-ориентированных систем что-нибудь вроде UML и каких-либо методологий? Если нет, то назвать WinAPI объектно-ориентированной системой нельзя. Пресловутые полиморфизм с инкапсуляцией и т.п. можно разглядеть в совершенно неожиданных местах. Но это не значит что все, где это можно разглядеть, разрабатывалось с объектно-ориентированной парадигмой в уме. Действительно, если шимпанзе ходит на двух ногах — это еще не повод называть шимпанзе человеком. Сервис ориентированная архитектура — это ООП или не ООП? Пока не сможете ткнуть пальцем в конкретную методологию реализации, все эти рассуждения, является ли WinAPI объектно-ориентированной системой или не является — полная аналогия с эпизодом "синкопа-не-синкопа" в одном известном фильме.
1>Как минимум обратное тоже не верно. Нельзя однозначно утверждать, что WinAPI не является ООП подходом.
Сама жизнь является ООП-подходом, а что с того? Есть конкретные системы для разработки конкретного результата. А что дают рассуждения, насколько процедурная WinAPI соответствует перечисленным человеком Х необходимым и достаточным требованиям? А перечисленным человеком Y? А являются ли эти требования действительно достаточными и действительно необходимыми? Все это софистика: "Стакан наполовину полон или наполовину пуст". Не более того.
1>А насчет UML — ДА, разработано. Вы забыли, что UML это не только модель классов.
Ссылку на конкретную книгу дайте, пожалуйста. Лично я не встречал таких книг или методологий, которые бы показывали и предписывали как же все-таки следует правильно и почему на колбэках строить наследование на процедурных языках. Максимум — какие-нибудь внутрикорпоративные конвенции, которые нигде не являются стандартом кроме как у конкретной группы разработчиков в конкретной организации в конкретное время. И если эти ad-hoc конвенции удовлетворяют каким-то или даже всем пунктам, перечисленным X или Y, это не делает эти конвенции ОО-системами программирования. Только в сознании отдельных ее создателей, которые теми или иными конкретными способами взяли и решили конкретные проблемы. Потому что если рассуждать как вы, в названиях GetWindowTextA и GetWindowTextW можно увидеть полиморфизм и проникнуться глубиной ОО-миросозерцания авторов этой конвенции. Непонятно только, почему никто так же не делает?
Re[27]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, FR, Вы писали:
V>>Ну и напоследок. Когда ООП еще не было столь популярно уже успел оформиться в модульном программировании некий стиль "хорошего тона" — в точности такой же, как я показал на примере Speex. Дело оставалось за малым — поддержать этот стиль в языках. Но от языковой поддержки ничего существенного не изменилось (кроме синтаксиса) для таких программ, написанных по правилам "хорошего тона" для модульного ПО.
FR>Это структурное программирование + абстрактные типы данных + модульность. FR>И сформировалось оно все-таки пораньше чем мейнстримный сейчас (C++/C#/Java) ООП. FR>И это по моему не ООП, наследования нет и полиморфизм без виртуальных методов.
Виртуальные методы там есть, ес-но, полиморфизм работает на указателях на ф-ии. Просто таблица виртуальных ф-ий описана "ручками". Наследование структур — агрегация. Наследование поведения — повторное использование кода над агрегированными структурами. Там это всё в полный рост. Сдается мне, что язык С был выбран по соображениям более широкого распространения компилятора и ни по каким причинам более.
Про абстрактные типы данных замечание уже делал рядом: структурное программирование + абстрактные типы данных — это и есть ООП, ИМХО. Просто в мейнстриме популярен такой синтаксис, что ф-ии переползли в т.н. "методы". Но ведь так не везде: например, в объектном Лиспе методы объектов оформлены как внешние ф-ии, как в показанном примере с кодеком. ИМХО, это всего-лишь детали синтаксиса используемого языка, не особо влияющие на подход к проектированию и реализации.
Здравствуйте, FR, Вы писали:
FR>А это уже замыленный ООП взгляд FR>А я могу сказать что вижу размазанный алгебраический тип данных
FR>
FR>type brush = Hatch | Solid | Pattern
FR>
FR>и это эмуляция ФП
АлгТД — это никакая не эмуляция ФП.
ФП — это отсутствие мутабельных состояний + ФВП.
А способ диспетчеризации для достижения полиморфизма не принципиален. Для простых перечислений в ПМ вроде бы и так и так таблица диспетчеризации получается.
F>Ага, а современные машины отличаются от первых тарантасов наличием парктроника.
Абстрактные типы данных — это уже не такой уж и тарантас. По меркам автомобилестроения это как минимум 60-е. Дизайн и ходовая ходовая порша с тех пор не особо изменились.
А так-то да... ничего нового. Электромобили были еще в начале века. Ни принцип действия, ни КПД, ни массо-габаритные показатели электромоторов фактически не изменилось за это время, се ля ви. (Всё уже было изобретено и отшлифовано на электростанциях). Существенный прогресс был только в технологии аккумуляторов.
Здравствуйте, Fortnum, Вы писали:
F>А парадигма состояния и кода, состояние это изменяющего, — это парадигма ООП или концепция из другой парадигмы в ООП украденная?
Не понял, кто кого у кого украл? Изначально программы рассматривались как описание работы эквивалентного автомата. Переход от глобального состояния к динамически создаваемым экземплярам взаимодействующих автоматов и был переходом к современной концепции ООП.
Что сказать-то хотел?
Re[28]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
FR>>Это структурное программирование + абстрактные типы данных + модульность. FR>>И сформировалось оно все-таки пораньше чем мейнстримный сейчас (C++/C#/Java) ООП. FR>>И это по моему не ООП, наследования нет и полиморфизм без виртуальных методов.
V>Виртуальные методы там есть, ес-но, полиморфизм работает на указателях на ф-ии. Просто таблица виртуальных ф-ий описана "ручками".
В WinAPI? В публичных интерфейсах?
Не припоминаю такого.
COM конечно не рассматриваем, это уже совсем другая песня.
А в си вообще, да нормальная практика.
V>Наследование структур — агрегация. Наследование поведения — повторное использование кода над агрегированными структурами. Там это всё в полный рост.
Снаружи что-то не видно.
Наоборот почти везде в прозрачных структурах явный cbSize или отдельная EX структура.
V>Сдается мне, что язык С был выбран по соображениям более широкого распространения компилятора и ни по каким причинам более.
Это да, хотя ходят смутные слухи что был сначала паскаль.
V>Про абстрактные типы данных замечание уже делал рядом: структурное программирование + абстрактные типы данных — это и есть ООП, ИМХО. Просто в мейнстриме популярен такой синтаксис, что ф-ии переползли в т.н. "методы". Но ведь так не везде: например, в объектном Лиспе методы объектов оформлены как внешние ф-ии, как в показанном примере с кодеком. ИМХО, это всего-лишь детали синтаксиса используемого языка, не особо влияющие на подход к проектированию и реализации.
С этим я не согласен.
Тот же полиморфизм на виртуальных функциях с наследованием очень существенно меняет структуру кода,
и на си в таком стиле писать очень неудобно.
Re[28]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
V>Про абстрактные типы данных замечание уже делал рядом: структурное программирование + абстрактные типы данных — это и есть ООП, ИМХО. Просто в мейнстриме популярен такой синтаксис, что ф-ии переползли в т.н. "методы".
, что "Windows API — это самая настоящая ОО-концепция". Так где в WinAPI используются "абстрактные типы данных"? Или таковыми вы считаете соглашение WinAPI об использовании первого поля структур для sizeof? Хм, по-вашему, вдруг получается, что Windows API — это уже не настоящая ОО-концепция, или как? Или сейчас будете играть понятиями "концепция", "принцип", "парадигма" и т.п.?
FR>>и это эмуляция ФП
V>АлгТД — это никакая не эмуляция ФП. V>ФП — это отсутствие мутабельных состояний + ФВП.
Остальное подтянется за АлгТД
V>А способ диспетчеризации для достижения полиморфизма не принципиален. Для простых перечислений в ПМ вроде бы и так и так таблица диспетчеризации получается.
Здравствуйте, vdimas, Вы писали:
F>>Ага, а современные машины отличаются от первых тарантасов наличием парктроника. V>Абстрактные типы данных — это уже не такой уж и тарантас. По меркам автомобилестроения это как минимум 60-е. Дизайн и ходовая ходовая порша с тех пор не особо изменились. V>А так-то да... ничего нового. Электромобили были еще в начале века. Ни принцип действия, ни КПД, ни массо-габаритные показатели электромоторов фактически не изменилось за это время, се ля ви. (Всё уже было изобретено и отшлифовано на электростанциях). Существенный прогресс был только в технологии аккумуляторов.
Здравствуйте, vdimas, Вы писали:
F>>А парадигма состояния и кода, состояние это изменяющего, — это парадигма ООП или концепция из другой парадигмы в ООП украденная? V>Не понял, кто кого у кого украл? Изначально программы рассматривались как описание работы эквивалентного автомата. Переход от глобального состояния к динамически создаваемым экземплярам взаимодействующих автоматов и был переходом к современной концепции ООП. V>Что сказать-то хотел?
Хотел сказать, что класс ООП инкапсулирует в себе, в единой сущности, как состояние, так и код это состояние изменяющий. Хотя теперь я понял, что вы не видите особой разницы между классом и глобальными переменными, как между современными автомобилями и первыми тарантасами. Понятно, почему вы не поняли, что я сказал.
Здравствуйте, Fortnum, Вы писали:
F>Простой вопрос. Разработано ли для WinAPI и подобных псевдообъектно-ориентированных систем что-нибудь вроде UML и каких-либо методологий?
UML появился значительно позже WinAPI.
F>Если нет, то назвать WinAPI объектно-ориентированной системой нельзя.
Лопни мои глаза!!! Всё что было до UML нельзя назвать объектно-ориентированным! В мемориз адназначна!
F>Пресловутые полиморфизм с инкапсуляцией и т.п. можно разглядеть в совершенно неожиданных местах.
Еще бы! Это же крайне удобные шаблоны проектирования — грех не попользовать.
F>Но это не значит что все, где это можно разглядеть, разрабатывалось с объектно-ориентированной парадигмой в уме.
"Все что плавает как утка, крякает как утка,"... ну ты понял.
В общем, можно и нужно. Там, где речь идет об изолированных состояниях-"черных ящиках", изменяемых императивным образом, — там работает ОО-подход. Бо в этом и состоит ОО-парадигма. Даже если кто-то пользует эту парадигму совершенно случайно или не отдавая себе в этом отчета.
F>Действительно, если шимпанзе ходит на двух ногах — это еще не повод называть шимпанзе человеком.
Потому что определение человека другое и шимпанзе ему не противоречит, а ты трижды в одном посте пытался противоречить определению ООП.
F>Сервис ориентированная архитектура — это ООП или не ООП?
Это сервис-ориентированная архитектура. Это считай модульный подход в сочетании с сетевыми технологиями. Но внутренняя реализация такого "модуля" может быть произвольной.
F>Пока не сможете ткнуть пальцем в конкретную методологию реализации,
Еще раз — произвольной.
F>все эти рассуждения, является ли WinAPI объектно-ориентированной системой или не является
Лишь небольшую часть WinAPI можно с натяжкой отнести к сервис-ориентированным. Так что в целом можно сказать, что WinPI НЕ является сервис-ориентированной системой. Увы. Сплошной statefull и нетривиальный многошаговый протокол работы с различными системными объектами.
Здравствуйте, vdimas, Вы писали:
V>Лопни мои глаза!!! Всё что было до UML нельзя назвать объектно-ориентированным! В мемориз адназначна! V>UML появился значительно позже WinAPI.
Я не утверждал, что "Всё что было до UML нельзя назвать объектно-ориентированным". Это ваше утверждение. Сами сказали, сами удивились. Я лишь попросил привести пример методологии или хотя бы книги по разработке в ОО-парадигме на процедурных ЯП. Ответа пока так и не дождался. Странно. Концепция процедурного или структурного программирования появилась вроде бы задолго до распространения ООП, а вот ни одной книги, как строить на них LOB-приложения нет. Почему-то все предпочитают ООЯП. К чему тогда софистика, является ли WinAPI объектно-ориентированной или нет? Я лишь о том, что спор этот лишен смысла, и при желании здесь доказать можно все что угодно, а потом доказать ровно обратное.
F>>Пресловутые полиморфизм с инкапсуляцией и т.п. можно разглядеть в совершенно неожиданных местах. V>Еще бы! Это же крайне удобные шаблоны проектирования — грех не попользовать.
Вообще-то ОО взято из реальной жизни, а не наоборот.
F>>Но это не значит что все, где это можно разглядеть, разрабатывалось с объектно-ориентированной парадигмой в уме. V>"Все что плавает как утка, крякает как утка,"... ну ты понял. V>В общем, можно и нужно. Там, где речь идет об изолированных состояниях-"черных ящиках", изменяемых императивным образом, — там работает ОО-подход. Бо в этом и состоит ОО-парадигма. Даже если кто-то пользует эту парадигму совершенно случайно или не отдавая себе в этом отчета.
В том-то и дело, что если этот кто-то использует ООП "случайно или не отдавая себе в этом отчета", конечный продукт называть объектно-ориентированным — бессмысленно. А то, что оно в той или иной степени получится объектно-ориентированной, так сама жизнь объектно-ориентированная, а программирование — это моделирование реальной жизни. Следовательно, для сложных систем "совершенно случайно или не отдавая себе в этом отчета" вполне себе может получится объектно-ориентированный продукт. Но, еще раз, если он таковым не задумывался изначально, это псевдо-ОО, то есть "не ООП".
F>>Действительно, если шимпанзе ходит на двух ногах — это еще не повод называть шимпанзе человеком. V>Потому что определение человека другое и шимпанзе ему не противоречит, а ты трижды в одном посте пытался противоречить определению ООП.
, что "структурное программирование + абстрактные типы данных — это и есть ООП" — ваше, а не моё. А где я пытался противоречить определению ООП, я не увидел.
F>>Сервис ориентированная архитектура — это ООП или не ООП? V>Это сервис-ориентированная архитектура. Это считай модульный подход в сочетании с сетевыми технологиями. Но внутренняя реализация такого "модуля" может быть произвольной.
Статический класс или синглтон — это разве не сервис-ориентированная архитектура? Причем здесь сетевые технологии?
F>>все эти рассуждения, является ли WinAPI объектно-ориентированной системой или не является V>Лишь небольшую часть WinAPI можно с натяжкой отнести к сервис-ориентированным. Так что в целом можно сказать, что WinPI НЕ является сервис-ориентированной системой. Увы. Сплошной statefull и нетривиальный многошаговый протокол работы с различными системными объектами.
Я не утверждал, что WinAPI относится к сервис-ориентированным архитектурам.
Здравствуйте, Fortnum, Вы писали:
F>Здравствуйте, 11molniev, Вы писали:
F>>>Простой вопрос. Разработано ли для WinAPI и подобных псевдообъектно-ориентированных систем что-нибудь вроде UML и каких-либо методологий? Если нет, то назвать WinAPI объектно-ориентированной системой нельзя. Пресловутые полиморфизм с инкапсуляцией и т.п. можно разглядеть в совершенно неожиданных местах. Но это не значит что все, где это можно разглядеть, разрабатывалось с объектно-ориентированной парадигмой в уме. Действительно, если шимпанзе ходит на двух ногах — это еще не повод называть шимпанзе человеком. Сервис ориентированная архитектура — это ООП или не ООП? Пока не сможете ткнуть пальцем в конкретную методологию реализации, все эти рассуждения, является ли WinAPI объектно-ориентированной системой или не является — полная аналогия с эпизодом "синкопа-не-синкопа" в одном известном фильме.
1>>Как минимум обратное тоже не верно. Нельзя однозначно утверждать, что WinAPI не является ООП подходом.
F>Сама жизнь является ООП-подходом, а что с того? Есть конкретные системы для разработки конкретного результата. А что дают рассуждения, насколько процедурная WinAPI соответствует перечисленным человеком Х необходимым и достаточным требованиям? А перечисленным человеком Y? А являются ли эти требования действительно достаточными и действительно необходимыми? Все это софистика: "Стакан наполовину полон или наполовину пуст". Не более того.
Может всетаки наоборот — ООП является способом абстрагировать объекты окружающего мира? Вы вообще выделили как критерий объектной-ориентированности наличие UML.
ООП — это не конкретная система для разработки конкретного результата как Вы утверждаете. Это идея.
И WinAPI такое же ООП, как и C++, C#, Java, Python и прочие современные реализации в которых нет сообщений.
И хоть убейте, я лично не понимаю, почему:
object = new class(param);
object.method(param);
delete object
не ООП. Я в упор не вижу разницы, кроме немного иной формы записи. И автоматического вызова деструкторов. По "Пресловутые полиморфизм с инкапсуляцией" вы проехались сами.
А если говорить, про WinAPI, то пример выше выражаться в:
HANDLE h = CreateFile();
WriteFile(h, ...);
CloseHandle(h);
1>>А насчет UML — ДА, разработано. Вы забыли, что UML это не только модель классов.
F>Ссылку на конкретную книгу дайте, пожалуйста. Лично я не встречал таких книг или методологий, которые бы показывали и предписывали как же все-таки следует правильно и почему на колбэках строить наследование на процедурных языках. Максимум — какие-нибудь внутрикорпоративные конвенции, которые нигде не являются стандартом кроме как у конкретной группы разработчиков в конкретной организации в конкретное время. И если эти ad-hoc конвенции удовлетворяют каким-то или даже всем пунктам, перечисленным X или Y, это не делает эти конвенции ОО-системами программирования. Только в сознании отдельных ее создателей, которые теми или иными конкретными способами взяли и решили конкретные проблемы. Потому что если рассуждать как вы, в названиях GetWindowTextA и GetWindowTextW можно увидеть полиморфизм и проникнуться глубиной ОО-миросозерцания авторов этой конвенции. Непонятно только, почему никто так же не делает?
RFC по TCP/IP устроит? Модель состояний это ведь тоже UML. Книг предписывающих что вы описали я на вскидку не припоминаю, но к чему вы вообще это написали
Это вы как бы сами с собой спорите. Диалог путем выдвижения собственных предположений и их оспаривания можно проводить и без меня.
К слову в названиях GetWindowTextA и GetWindowTextW я тоже особого полиморфизма не вижу. И вообще затрудняюсь вспомнить какое нибудь название в котором можно увидеть полиморфизм. Разве что в глубинах boost-а скрывается что-то такое.
Здравствуйте, 11molniev, Вы писали:
F>>Сама жизнь является ООП-подходом, а что с того? Есть конкретные системы для разработки конкретного результата. А что дают рассуждения, насколько процедурная WinAPI соответствует перечисленным человеком Х необходимым и достаточным требованиям? А перечисленным человеком Y? А являются ли эти требования действительно достаточными и действительно необходимыми? Все это софистика: "Стакан наполовину полон или наполовину пуст". Не более того.
1>Может всетаки наоборот — ООП является способом абстрагировать объекты окружающего мира? Вы вообще выделили как критерий объектной-ориентированности наличие UML. 1>ООП — это не конкретная система для разработки конкретного результата как Вы утверждаете. Это идея. 1>И WinAPI такое же ООП, как и C++, C#, Java, Python и прочие современные реализации в которых нет сообщений.
Наконец-то. С этого и надо начинать. В том-то и дело, что ООП — это прежде всего ход мыслей. А UML — это всего лишь эффективный способ направить ход мыслей в правильное ОО-русло. И как критерий я выделил не UML, а "UML и методологию", хотя бы одну книгу. Просто не видел таких методологий для разработки ОО-систем на том же С, или на другом не-ОО ЯП: чтобы на не-ООЯП демонстрировалась ОО-идея и предписывался бы ОО-ход мыслей. На основе ОО ЯП с использованием UML таких книг полно. Любая книга по паттернам. Все они подразумевают концепцию класса. Покажите мне книгу по ООП, где бы не использовалась концепция класса, а где описывалась ОО-идея на основе системы по типу WinAPI. Правда, интересно было бы почитать такую. А раз нет таких книг, то и WinAPI — не ОО-система. Хоть она на нее и похожа. Первые тарантасы — тоже относительно автомобили. Но какой смысл спорить, являются ли они автомобилями в сравнении с современными сложными агрегатами, которые уже без водителя ездят.
1>И хоть убейте, я лично не понимаю, почему:
1>object = new class(param);
1>object.method(param);
1>delete object
1>не ООП. Я в упор не вижу разницы, кроме немного иной формы записи. И автоматического вызова деструкторов. 1>По "Пресловутые полиморфизм с инкапсуляцией" вы проехались сами.
Ну так, собственно, каким образом во втором примере можно реализовать полиморфизм и инкапсуляцию?
1>А если говорить, про WinAPI, то пример выше выражаться в:
1>HANDLE h = CreateFile();
1>WriteFile(h, ...);
1>CloseHandle(h);
Ничего, что для решения проблемы оюникодивания под CreateFile раскрывается макрос в CreateFileA или в CreateFileW? Это и есть один из вариантов AdHoc-полиморфизма, то есть как-бы-полиморфизма, то есть как-бы-ООП, то есть не-ООП.
F>>Максимум — какие-нибудь внутрикорпоративные конвенции, которые нигде не являются стандартом кроме как у конкретной группы разработчиков в конкретной организации в конкретное время. И если эти ad-hoc конвенции удовлетворяют каким-то пунктам, это не делает эти конвенции ОО-системами программирования. Только в сознании отдельных ее создателей, которые теми или иными конкретными способами взяли и решили конкретные проблемы. Потому что если рассуждать как вы, в названиях GetWindowTextA и GetWindowTextW можно увидеть полиморфизм и проникнуться глубиной ОО-миросозерцания авторов этой конвенции. Непонятно только, почему никто так же не делает?
1>RFC по TCP/IP устроит?
Это описание одной конкретной системы, решающей одну конкретную проблему. Это не методология разработки ПО и даже не методология разработки ПО какого-либо типа. Это описание конкретного продукта, такое же как описание WinAPI.
1>Модель состояний это ведь тоже UML.
Да, но состояний чего? В процедурном ЯП опять же упираемся в отсутствие инкапсуляции в терминах UML, то есть в терминах нормальной ООП.
1>К слову в названиях GetWindowTextA и GetWindowTextW я тоже особого полиморфизма не вижу. И вообще затрудняюсь вспомнить какое нибудь название в котором можно увидеть полиморфизм. Разве что в глубинах boost-а скрывается что-то такое.
Смотрите в самом низу здесь (Unicode and ANSI names): GetWindowTextW (Unicode) and GetWindowTextA (ANSI) — это конкретное решение конкретной проблемы.
PS. Я не утверждаю, что WinAPI не-ООП или ООП. Есть там — есть элементы ООП. Точно такие же элементы ООП, которые есть в VBA. В VBA нет наследования, что не мешает многим называть его ОО ЯП и ОО-системой разработки, т.к. там есть модули классов и с Automatio он работает. Но VBA — это система для разработки приложений, которые можно разрабатывать ОО-способом (можно и не-ОО). Но как можно разрабатывать ОО-способом под WinAPI на чистом процедурном ЯП? Какой смысл вообще в этом споре, я не понимаю. Если бы практически какой-то результат давала такая разработка, я бы понял.
F>>>А парадигма состояния и кода, состояние это изменяющего, — это парадигма ООП или концепция из другой парадигмы в ООП украденная? V>>Не понял, кто кого у кого украл? Изначально программы рассматривались как описание работы эквивалентного автомата. Переход от глобального состояния к динамически создаваемым экземплярам взаимодействующих автоматов и был переходом к современной концепции ООП. V>>Что сказать-то хотел?
F>Хотел сказать, что класс ООП инкапсулирует в себе, в единой сущности, как состояние, так и код это состояние изменяющий.
Т.е. определение автомата ты забыл? Почему бы не освежить и не сравнить с тем, что ты только что написал? Я-то, по наивности своей, рассчитывал, что одного упоминания "автомата" будет достаточно... ан нет.
F>Хотя теперь я понял, что вы не видите особой разницы между классом и глобальными переменными,
Т.е. даже после выделения слова "экземпляры" ты не сумел сфокусироваться на главном отличии первых программ от современных? Дык, никогда не поздно попробовать еще раз.
F>как между современными автомобилями и первыми тарантасами. Понятно, почему вы не поняли, что я сказал.
Здравствуйте, vdimas, Вы писали:
V>>>Изначально программы рассматривались как описание работы эквивалентного автомата. Переход от глобального состояния к динамически создаваемым экземплярам взаимодействующих автоматов и был переходом к современной концепции ООП. F>>Хотел сказать, что класс ООП инкапсулирует в себе, в единой сущности, как состояние, так и код это состояние изменяющий. V>Т.е. определение автомата ты забыл? Почему бы не освежить и не сравнить с тем, что ты только что написал? Я-то, по наивности своей, рассчитывал, что одного упоминания "автомата" будет достаточно... ан нет. V>Т.е. даже после выделения слова "экземпляры" ты не сумел сфокусироваться на главном отличии первых программ от современных? Дык, никогда не поздно попробовать еще раз.
Я прочитал и понял вас. Не понял только, кто не давал экземпляры автоматов динамически создавать на процедурных ЯП? Так бы и писали все до сих пор по аналогии с WinAPI. Только не пишут ведь, даже не пытаются. Без классов оно конечно можно, но только никому не хочется.
Следуя вашему изложению (см. выше "современная концепция ООП"), "старая" концепция ООП никому не нужна, никто ее не пропагандирует, и чего уж там, не-ООП это концепция, старая-то, а?
V>Точно, из-за кривой аналогии на автомобилях!
Вот и я о том же, ездили бы поголовно все до сих пор на 2106, чем не машина? Ну не ездят сейчас на самодвижущихся паровых тележках, не средство передвижения это, куда уж им до автомобиля.
Здравствуйте, Fortnum, Вы писали:
1>>Может всетаки наоборот — ООП является способом абстрагировать объекты окружающего мира? Вы вообще выделили как критерий объектной-ориентированности наличие UML. 1>>ООП — это не конкретная система для разработки конкретного результата как Вы утверждаете. Это идея. 1>>И WinAPI такое же ООП, как и C++, C#, Java, Python и прочие современные реализации в которых нет сообщений.
F>Наконец-то. С этого и надо начинать. В том-то и дело, что ООП — это прежде всего ход мыслей. А UML — это всего лишь эффективный способ направить ход мыслей в правильное ОО-русло. И как критерий я выделил не UML, а "UML и методологию", хотя бы одну книгу. Просто не видел таких методологий для разработки ОО-систем на том же С, или на другом не-ОО ЯП: чтобы на не-ООЯП демонстрировалась ОО-идея и предписывался бы ОО-ход мыслей. На основе ОО ЯП с использованием UML таких книг полно. Любая книга по паттернам. Все они подразумевают концепцию класса. Покажите мне книгу по ООП, где бы не использовалась концепция класса, а где описывалась ОО-идея на основе системы по типу WinAPI. Правда, интересно было бы почитать такую. А раз нет таких книг, то и WinAPI — не ОО-система. Хоть она на нее и похожа. Первые тарантасы — тоже относительно автомобили. Но какой смысл спорить, являются ли они автомобилями в сравнении с современными сложными агрегатами, которые уже без водителя ездят.
UML это просто стандарт графического представления. Чтоб вы могли понять мои рисунки, а я ваши. Это не способ направить ход мыслей.
Интересный ход мыслей — нет книги, значит нет объектной ориентированности. И все такие современные сложные агрегаты с паттернами (вы в курсе, что паттерны термин применимый не только к ООП?) ОО-систем на ОО-языках последние двадцать лет ездят на тарантасах.
Впрочем не знаю как вы относитесь к COM. Если на ваш взгляд это нечто объектно-ориентированное — то сгодиться любая книжка по этой технологии.
1>>По "Пресловутые полиморфизм с инкапсуляцией" вы проехались сами. F>Ну так, собственно, каким образом во втором примере можно реализовать полиморфизм и инкапсуляцию?
Никаким. Они уже реализованы.
F>Ничего, что для решения проблемы оюникодивания под CreateFile раскрывается макрос в CreateFileA или в CreateFileW? Это и есть один из вариантов AdHoc-полиморфизма, то есть как-бы-полиморфизма, то есть как-бы-ООП, то есть не-ООП.
Полиморфизм, это возможность открыть с помощью CreateFileW и файл и диск и именованный пайп и много чего ещё. Таблица вызовов в глубинах ядра ну прям как в С++.
Я про макрос вам ничего не говорил, так что к нему просьба не придираться.
1>>RFC по TCP/IP устроит? F>Это описание одной конкретной системы, решающей одну конкретную проблему. Это не методология разработки ПО и даже не методология разработки ПО какого-либо типа. Это описание конкретного продукта, такое же как описание WinAPI.
Одной. А чё у планировщиков потоков/ввода-вывода, менеджера памяти и прочих подсистем этих моделей нет? Я привел этот пример ибо стандарт открытый. А большая часть документации на винду закрыта. Насчет методологии разработки ПО... ну даже не знаю. Может нам в отдельную тему вынести дискурсию (хотя скорей уж демагогию) о необходимости и пользе методологий в их практическом приложении? Ведь взять любую подсистему из ядра винды или линуха — ну вот не по методологии вроде бы сделано, но код то хороший. И сделано таки правильно.
1>>Модель состояний это ведь тоже UML. F>Да, но состояний чего? В процедурном ЯП опять же упираемся в отсутствие инкапсуляции в терминах UML, то есть в терминах нормальной ООП.
Люди, кони... Вы определитесь, язык программирования или UML. И поймите, что концепции (вы ж согласились, что ООП это идея?) к реализации не привязана. Инкапсуляция это сокрытие реализации — сделает это компилятор или вы разницы нет. Поэтому утверждение об отсутствии инкапсуляции в языке программирования выглядит странно.
Тьфу. В конце концов вспомните cfront. Вот вам и отсутствие инкапсуляции в процедурном языке.
1>>К слову в названиях GetWindowTextA и GetWindowTextW я тоже особого полиморфизма не вижу. И вообще затрудняюсь вспомнить какое нибудь название в котором можно увидеть полиморфизм. Разве что в глубинах boost-а скрывается что-то такое. F>Смотрите в самом низу здесь (Unicode and ANSI names): GetWindowTextW (Unicode) and GetWindowTextA (ANSI) — это конкретное решение конкретной проблемы.
Ну и что из этого следует? Смилуйтесь — разжуйте.
F>PS. Я не утверждаю, что WinAPI не-ООП или ООП. Есть там — есть элементы ООП. Точно такие же элементы ООП, которые есть в VBA. В VBA нет наследования, что не мешает многим называть его ОО ЯП и ОО-системой разработки, т.к. там есть модули классов и с Automatio он работает. Но VBA — это система для разработки приложений, которые можно разрабатывать ОО-способом (можно и не-ОО). Но как можно разрабатывать ОО-способом под WinAPI на чистом процедурном ЯП? Какой смысл вообще в этом споре, я не понимаю. Если бы практически какой-то результат давала такая разработка, я бы понял.
Я практически полностью согласен с этим утверждением.
Здравствуйте, Fortnum, Вы писали:
F>>>Ага, а современные машины отличаются от первых тарантасов наличием парктроника. V>>Абстрактные типы данных — это уже не такой уж и тарантас. По меркам автомобилестроения это как минимум 60-е. Дизайн и ходовая ходовая порша с тех пор не особо изменились. V>>А так-то да... ничего нового. Электромобили были еще в начале века. Ни принцип действия, ни КПД, ни массо-габаритные показатели электромоторов фактически не изменилось за это время, се ля ви. (Всё уже было изобретено и отшлифовано на электростанциях). Существенный прогресс был только в технологии аккумуляторов.
F>Ну хотя бы микроконтроллеры возьмите в расчет.
Легко! Только при чем тут автомобиль? Давай уже тогда утюги и стиралки. Они ведь тоже с контроллерами! И процесс вращения барабана теперь вовсе не такой, как раньше, когда на этих тупых реле. Он теперь ого-гоо! Только всей разницы, что раньше таймер был механический, а теперь электронный. Ну и еще в том, что сложные программы стояли только на дорогих моделях, а на дешевых режимы переключались вручную, а теперь эти же программы стоят на всех, потому что микроконтроллер уравнял их в цене. Этот микроконтроллер взял на себя автоматику, не принеся ничего нового. Так же, как в автомобилях, заметь. Я изучал на УПК еще при Союзе устройство автомобилей — не было никаких контроллеров. А все современные блоки автомобилей — были. И все были изобретены задолго даже до второй мировой. Просто были на автоматике. Где на реле, где на транзисторах (гораздо позже), а где и вовсе автоматика на самой что ни на есть механике. Например, банальный автомобильный гудок всё это время работал от нагревания пластины из 2-х слоев, её искривления, размыкания цепи и моментального остывания. Или тоже самое на соленоиде, но все-равно через размыкание контактов. Вот так оно и вибрировало на 400-800 Герц. Даже парктроники были задолго до микропроцессоров, бо вовсе не микропроцессор в парктронике главный.
ИМХО, самое время сделать паузу и помедитировать над тем, зачем же микропроцессор.
Здравствуйте, FR, Вы писали:
V>>АлгТД — это никакая не эмуляция ФП. V>>ФП — это отсутствие мутабельных состояний + ФВП. FR>Остальное подтянется за АлгТД
Не факт.
V>>А способ диспетчеризации для достижения полиморфизма не принципиален. Для простых перечислений в ПМ вроде бы и так и так таблица диспетчеризации получается. FR>Нет только не это
Куда же без этого? Для разных типов кистей используются разные алгоритмы заливки.
A>Ага, остается только наследование. Последнее делится на наследование интерфейса и наследование реализации.
Чтоб окончательно запутать спорящих, добавлю, что наследование интерфейсов появилось совсем недавно, в так называемом энтерпрайзе. Причиной послужила конкуренция между Java и C# в этом очень и очень денежном сегменте, где 9 проектов из 10 — распильные. Это решение (очень, кстати, красивое) нашли просто методом тыка, в неравной борьбе с индусами и т.п. кого там набирают через сайты по трудоустройству.
В C++ начала 90-х его не было, как не было и в тогдашней Жаббе с Оберонами... да и Алан Кей, создавая свои чёрные ящики с внутренней памятью, не то наследование имел в виду.
Здравствуйте, Fortnum, Вы писали:
F>Я прочитал и понял вас. Не понял только, кто не давал экземпляры автоматов динамически создавать на процедурных ЯП?
Эти практики должны были устояться и оформиться в виде отдельной парадигмы. Мы же не о теории рассуждаем, а о сугубо практических методологиях к решению задач. ООП — это просто методология. Одна из.
F>Так бы и писали все до сих пор по аналогии с WinAPI.
Дык, SmallTalk и работает по аналогии с WinAPI. Чуть ли не первый ОО-язык.
F>Только не пишут ведь, даже не пытаются. Без классов оно конечно можно, но только никому не хочется.
Бывают ОО-языки без классов. Зато с объектами. Не смешивай типизацию и ООП, а то это тебя путает.
F>Следуя вашему изложению (см. выше "современная концепция ООП"), "старая" концепция ООП никому не нужна, никто ее не пропагандирует, и чего уж там, не-ООП это концепция, старая-то, а? V>>Точно, из-за кривой аналогии на автомобилях! F>Вот и я о том же, ездили бы поголовно все до сих пор на 2106, чем не машина? Ну не ездят сейчас на самодвижущихся паровых тележках, не средство передвижения это, куда уж им до автомобиля.
Я и не спорил насчет синтаксического сахарка... Удобнее с сахарком — ради бога. Только это ничего не меняет. Как тормозили делегаты на дотнете, так и тормозят, когда "сахарные" лямбды к ним приводятся.
В общем, заканчивай с кривыми аналогиями. ООП — это подход к решению задачи, паттерн проектирования. Просто в некоторые языки этот паттерн встроен.
V>>Лопни мои глаза!!! Всё что было до UML нельзя назвать объектно-ориентированным! В мемориз адназначна! V>>UML появился значительно позже WinAPI.
F>Я не утверждал, что "Всё что было до UML нельзя назвать объектно-ориентированным". Это ваше утверждение.
Ты требовал, чтобы книги и прочая вода, типа UML? появились ДО устаканивания методологии. Это перебор.
F>Я лишь попросил привести пример методологии или хотя бы книги по разработке в ОО-парадигме на процедурных ЯП.
Зачем?
F>Ответа пока так и не дождался. Странно. Концепция процедурного или структурного программирования появилась вроде бы задолго до распространения ООП, а вот ни одной книги, как строить на них LOB-приложения нет.
(что за LOB?)
Книги — это бизнес. Особенно книги по ООП. По факту на сегодня не существует формальной теории ООП, не существует формальных правил ОО-анализа и не существует сугубо для ООП формальных оценок качества решения. Те, что используются — применимы так же к не ООП. Так что современные книги по ООП можно пустить на туалетную бумагу. Или просто на учебники по программирования. Например, Гради Буча я читал уже тогда, когда подобного уровня изложение читать малость подздновато. Надо было на 1-2-м курсах, не позже.
F>Почему-то все предпочитают ООЯП. К чему тогда софистика, является ли WinAPI объектно-ориентированной или нет?
Это софистика лишь для тебя, т.к. ты не до конца понял про языки. WinAPI нейтрально к языку. В этом причина. Но уже COM — нет. Таки плюшки от объектности перевесили требования нейтральности. Кстати, расширения WinAPI, начиная с Win2000 зачастую шло в технологии COM. Ну и WinRT было окончательно в виде COM устаканено.
F>Я лишь о том, что спор этот лишен смысла, и при желании здесь доказать можно все что угодно, а потом доказать ровно обратное.
В каком месте он лишен смысла? Если не делать преждевременных выводов, а задавать вопросы и вникать в ответы — смысл будет.
F>>>Пресловутые полиморфизм с инкапсуляцией и т.п. можно разглядеть в совершенно неожиданных местах. V>>Еще бы! Это же крайне удобные шаблоны проектирования — грех не попользовать.
F>Вообще-то ОО взято из реальной жизни, а не наоборот.
Я думал ты про код...
Ну дык, любое программирование взято из "реальной жизни". Даже простая программка решения квадратного уравнения безо-всякого ООП. В отрыве от реальной жизни программирование не нужно.
F>В том-то и дело, что если этот кто-то использует ООП "случайно или не отдавая себе в этом отчета", конечный продукт называть объектно-ориентированным — бессмысленно.
Почему? Сплошь и рядом бывает, что люди независимо друг от друга изобретают одно и то же. В инженерии это происходит на многие порядки чаще, чем в науке, тем более, когда речь идет о практических приемах, а не фундаментальных. Идея ООП на поверхности. Ее почти одновременно изобрели многие обычные программисты, достигнув некоторого опыта в структурном программировании. Точно так же, как многие пользовались паттернами проектирования из GOF задолго до написания этой книги. Ничего удивительного здесь нет.
F>А то, что оно в той или иной степени получится объектно-ориентированной, так сама жизнь объектно-ориентированная, а программирование — это моделирование реальной жизни. Следовательно, для сложных систем "совершенно случайно или не отдавая себе в этом отчета" вполне себе может получится объектно-ориентированный продукт. Но, еще раз, если он таковым не задумывался изначально, это псевдо-ОО, то есть "не ООП".
Откуда ты знаешь, что он таким не задумывался изначально? Если ты рассуждаешь о моделировании, то именно таким и задумывался, т.к. классическое моделирование во времени именно и организуют как взаимодействие различных "сущностей". Тот факт, что при разработке не использовали термин ООП не будет означать, что сам подход не ООП.
F>>>Действительно, если шимпанзе ходит на двух ногах — это еще не повод называть шимпанзе человеком. V>>Потому что определение человека другое и шимпанзе ему не противоречит, а ты трижды в одном посте пытался противоречить определению ООП.
F>Утверждение
, что "структурное программирование + абстрактные типы данных — это и есть ООП" — ваше, а не моё.
И где здесь противоречие?
F>А где я пытался противоречить определению ООП, я не увидел.
Пытался в плане WinAPI, но у тебя не особо выходит. UML и шимпанзе — это никуда не годящиеся аргументы. ))
F>>>Сервис ориентированная архитектура — это ООП или не ООП? V>>Это сервис-ориентированная архитектура. Это считай модульный подход в сочетании с сетевыми технологиями. Но внутренняя реализация такого "модуля" может быть произвольной.
F>Статический класс или синглтон — это разве не сервис-ориентированная архитектура? Причем здесь сетевые технологии?
Потому что ноги популярности термина растут именно оттуда. Локально нет никакой причины делать так же. Синглтон, статический класс, пакет, модуль и неймспейс — это одна и та же сущность с т.з. декомпозиции. Не надо наделять синглтон или статический класс чем-то магическим — понятие модуля известно уже пол века. Статический класс — это лишь их эмуляция в отсутствии прямой поддержки свободных ф-ий в неймспейсах/пакетах (в джаве или дотнете, например).
Re[29]: Язык ДРАКОН — новая идея в программировании
V>>Виртуальные методы там есть, ес-но, полиморфизм работает на указателях на ф-ии. Просто таблица виртуальных ф-ий описана "ручками". FR>В WinAPI?
В моем примере процедурного АПИ для кодека.
FR>В публичных интерфейсах?
Ну, если интерфейс драйвера DC относится к WinAPI (а он таки относится к АПИ), то в публичных интерфейсах тоже.
FR>COM конечно не рассматриваем, это уже совсем другая песня.
Нормальная песня. Расширения WinAPI со времен Win2000 зачатую идут именно в COM. ИМХО от того, что его научились поддерживать все самые важные для индустрии языки. Т.е. COM нынче такой же "нейтральный", как раньше было процедурное АПИ.
V>>Наследование структур — агрегация. Наследование поведения — повторное использование кода над агрегированными структурами. Там это всё в полный рост. FR>Снаружи что-то не видно.
Это я опять же про внутренности кодека писал.
FR>Наоборот почти везде в прозрачных структурах явный cbSize
Кстати, cbSize служит меткой типа структуры для многих случаев. Что-то типа концепции GetType().
FR>Это да, хотя ходят смутные слухи что был сначала паскаль.
V>>Про абстрактные типы данных замечание уже делал рядом: структурное программирование + абстрактные типы данных — это и есть ООП, ИМХО. Просто в мейнстриме популярен такой синтаксис, что ф-ии переползли в т.н. "методы". Но ведь так не везде: например, в объектном Лиспе методы объектов оформлены как внешние ф-ии, как в показанном примере с кодеком. ИМХО, это всего-лишь детали синтаксиса используемого языка, не особо влияющие на подход к проектированию и реализации.
FR>С этим я не согласен. FR>Тот же полиморфизм на виртуальных функциях с наследованием очень существенно меняет структуру кода,
Виртуальные ф-ии — это просто делегирование, т.е. +1 к косвенности вызова и ничего более. Такой трюк используют регулярно. Например, в интерфейсе дров для Linux надо заполнять таблицу ф-ий драйвера. Это полный аналог виртуальных ф-ий.
FR>и на си в таком стиле писать очень неудобно.
Да.
Но вы как-то упускаете из виду, что сначала устоялась некая практика программирования, и лишь ПОТОМ эту практику добавили в язык... получив С++.
Re[29]: Язык ДРАКОН — новая идея в программировании
V>Потому что ноги популярности термина растут именно оттуда. Локально нет никакой причины делать так же. Синглтон, статический класс, пакет, модуль и неймспейс — это одна и та же сущность с т.з. декомпозиции.
В синглтонах и модулях внутренние данные есть, а в остальных случаях их нет.
Подробнее написать не смогу, т.к. у меня сломался "Caps Lock" на клавиатуре из-за частого использования.
Но разница есть.
Здравствуйте, grosborn, Вы писали:
G>И сразу переврал. Это не object identifier, а внутренний идентификатор структур данных в ОС. Если бы это был object identifier, он так и назывался бы — object identifier. А он называется хэндл.
Он так и называется — object identifier.
G>Есть еще более обобщающий пример — CloseHandle().
Совершенно верно. G>То есть то что одна единственная процедура освобождает разные структуры данных ОС по идентификатору, это ты считаешь ОО подоходом.
Конечно. Вместе со всем остальным прогрессивным человечеством.
То есть вообразил себе, что все (группы процедур со струтурами), это на самом деле не процедуры со структурами, а объекты. То есть тебе даже не важна внутренняя реализация, не важна нотация, не важна даже (!)группировка процедур в объект, просто назвал объектом и вуаля — ООП готово.
Нет. Есть совершенно объективные критерии ООП. Если наличествует identity, behavior, и state, то нотация и внутренняя реализация вторичны.
G>Да я что, спорить не будут.
Это правильно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Fortnum, Вы писали:
F>Наконец-то. С этого и надо начинать. В том-то и дело, что ООП — это прежде всего ход мыслей. А UML — это всего лишь эффективный способ направить ход мыслей в правильное ОО-русло. И как критерий я выделил не UML, а "UML и методологию", хотя бы одну книгу. Просто не видел таких методологий для разработки ОО-систем на том же С, или на другом не-ОО ЯП: чтобы на не-ООЯП демонстрировалась ОО-идея и предписывался бы ОО-ход мыслей. На основе ОО ЯП с использованием UML таких книг полно. Любая книга по паттернам. Все они подразумевают концепцию класса. Покажите мне книгу по ООП, где бы не использовалась концепция класса, а где описывалась ОО-идея на основе системы по типу WinAPI. Правда, интересно было бы почитать такую. А раз нет таких книг,
Книги есть, практически классические, например Лисков Б., Гатэг Дж. "Использование абстракций и спецификаций при разработке программ".
Там используется языки CLU и паскаль (еще старый без ОО расширений). На си все что там изложено легко переносится. CLU конечно можно назвать ОО языком, но в современном понимании с большой натяжкой.
F>то и WinAPI — не ОО-система. Хоть она на нее и похожа. Первые тарантасы — тоже относительно автомобили. Но какой смысл спорить, являются ли они автомобилями в сравнении с современными сложными агрегатами, которые уже без водителя ездят.
WinAPI далеко не тарантас, когда ее разрабатывали уже существовали весьма зрелые ОО системы и как раз на них уже были
написаны оконные системы. Разработчики windows не могли об этом не знать и конечно на них не могла не повлиять ОО
методология.
Еще кроме windows есть скажем GTK+ тоже написанный на си и там ОО уже в полный рост и разработчики этого не скрывают.
Здравствуйте, Fortnum, Вы писали:
F>Простой вопрос. Разработано ли для WinAPI и подобных псевдообъектно-ориентированных систем что-нибудь вроде UML и каких-либо методологий?
Простите, но UML к OOP имеет примерно такое же отношение, как индульгенции к распятию. Т.е. UML (бесполезная надстройка) паразитирует над OOP. Без UML ООП прекрасно обойдётся.
F>Если нет, то назвать WinAPI объектно-ориентированной системой нельзя. Пресловутые полиморфизм с инкапсуляцией и т.п. можно разглядеть в совершенно неожиданных местах. Но это не значит что все, где это можно разглядеть, разрабатывалось с объектно-ориентированной парадигмой в уме. Действительно, если шимпанзе ходит на двух ногах — это еще не повод называть шимпанзе человеком. Сервис ориентированная архитектура — это ООП или не ООП?
Сервис-ориентированная архитектура является частным случаем ООП, т.к. идентичность, состояние, и поведение там чётко выделены.
Методологии совершенно ни при чём, мы говорим о математике.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>А что у нас будет с HPEN? Тоже алгебраический тип данных? И какая будет сигнатура у SelectObject?
Ну если проектировать в ФЯ стиле скорее всего никакого SelectObject не будет.
В заданных же рамках придется ослабить немного типизацию и использовать скажем Polymorphic variants
type brush = [`HatchBrush | `SolidBrush | `PatternBrush]
type pen = [`SolidPen | `DashPen | `DotPen]
exception Unknown_gdi_object
let select_brush dc b = ()
let select_pen dc p = ()
let select_object dc h = function
| #brush as brush -> select_brush dc brush
| #pen as pen -> select_pen dc pen
| _ -> raise Unknown_gdi_object
Здравствуйте, os24ever, Вы писали:
A>>Ага, остается только наследование. Последнее делится на наследование интерфейса и наследование реализации.
O>Чтоб окончательно запутать спорящих, добавлю, что наследование интерфейсов появилось совсем недавно, в так называемом энтерпрайзе.
Открываем пресловутый GOF, на 10й странице в первом абзаце предисловия:
...Безусловно, у вас не должно возникать необходимости лезть в словарь за разъяснением терминов «тип», «полиморфизм», и вам понятно, чем «наследование интерфейса» отличается от «наследования реализации».
С# появился намного позже.
O>Причиной послужила конкуренция между Java и C# в этом очень и очень денежном сегменте
Машина времени?
O>В C++ начала 90-х его не было, как не было и в тогдашней Жаббе с Оберонами...
Имеешь ввиду ключевое слово "interface"?
Здравствуйте, vdimas, Вы писали:
V>>>АлгТД — это никакая не эмуляция ФП. V>>>ФП — это отсутствие мутабельных состояний + ФВП. FR>>Остальное подтянется за АлгТД
V>Не факт.
Факт, вон бустовцы тихонечко замутили boost::variant и оглянутся не успели как оказались
по уши в boost::phoenix
Здравствуйте, os24ever, Вы писали:
V>>Потому что ноги популярности термина растут именно оттуда. Локально нет никакой причины делать так же. Синглтон, статический класс, пакет, модуль и неймспейс — это одна и та же сущность с т.з. декомпозиции. O>В синглтонах и модулях внутренние данные есть, а в остальных случаях их нет.
В статических классах тоже есть внутренние данные — статические мемберы.
Единственная принципиальная разница для синглтона — это возможность подержать некий, данный свыше, интерфейс. И все-равно это пляски с бубном вокруг непонятно чего — речь-то об обычной глобальной переменной. Вот, берем С++, создали где-то в единице компиляции глобальную переменную, но не отобразили в интерфейсе через заголовки, зато дали глобальную ф-ию — акцессор:
Здравствуйте, FR, Вы писали:
FR>>>Остальное подтянется за АлгТД V>>Не факт. FR>Факт, вон бустовцы тихонечко замутили boost::variant и оглянутся не успели как оказались FR>по уши в boost::phoenix
Дык, ленивость не означает функциональную чистоту. Феникс — это просто возможность писать код в рантайм, но со всеми плюшками императивного подхода в итоге. И да, зависимостей м/у variant и phoenix нет.
Здравствуйте, grosborn, Вы писали:
G>Ты чего пытаешься меня учить? Не то что бы я совсем против замечаний, но это же у тебя с логичностью суждений всегда проблемы. Даже в этом твоем посте несколько ошибок и проявление узости мышления (кроме формальных признаков есть еще и исторически сложившиеся использования понятий).
Давай по поводу исторически сложившихся понятий.
Функциональный подход — нет понятия состояния, нет понятие переменных. Дробим программу на функции. Функции не меняют исходные данные, они генерируют новый результат. 2 раза дернешь одну функцию, гарантировано получишь одинаковый результат. Функция sin является функциональным подходом. Функция rnd этим подходом не является, так как внутри состояние, нет детерминизма. printf также не является функциональным подходом, так как изменяет состояние — что то выводится на экран. Основное в программе — функции, функции работают с данными;
Процедурный подход — дробим программу на процедуры. Процедуры могут иметь постэффекты. Появляется понятие переменных, хранящих состояние. В том числе понятие глобальных переменных. Основное в программе — процедуры, которые работают с данными. И которые могут изменять эти данные. Частично есть сокрытие реализации, выраженное в модулях.
Объектно ориентированный подход. У нас, как и в процедурном подходе, есть состояние, есть постэффекты. Все заточено вокруг данных и операциями над этими данными. Данные и операции с ними тесно связаны. У нас появляется ограничение доступа к данным, когда нам не позволяют знать о внутренней реализации, все действия делаем через процедуры доступа (или методы). Частично это было и в процедурном подходе, с введением модулей. Однако, в отличие от процедурного подхода, в ООП подходе есть параллелизм, когда мы можем параллельно иметь различные экземпляры данных. Модуль, содержащий операцию rnd не позволяет работать параллельно, внутреннее состояние шарится между всеми пользователями. В ООП подходе с каждым пользователем связаны данные конкретного пользователя, и пользователи друг на друга не влияют. Дополнительно в ООП подходе появляются такие вещи, как полиморфизм и иерархия, в результате чего значительно усовершенстуются средства повторного использования кода. То есть с точки зрения пользователя мы можем унифицированно делать различные операции с данными, образующими иерархию. Вот ООП подход.
Итого. У нас есть API. Оно является комбинацией различных подходов.
y = sin(x) — строго функциональный подход.
writeln("Hello") — процедурный подход.
Набор процедур — z = createBrush(); setSlyle(z, COOLSTYLE); setColor(z, RED); draw(z); close(z); — это является ООП подходом. Соответствующий ему процедурный подход будет:
drawBrush(COOLSTYLE, RED);
В первом случае мы создаем внутреннюю структуру данных, мы понятия не имеем о том, как она устроена внутри, и через методы доступа устанавливаем интересующие нас характеристики результата. И с этой структурой данных у нас связан метод draw, который может рисовать очень и очень разные фигуры, в зависимости от того, какой идентификатор ему передали.
Во втором случае мы сразу же явно передаем всю информацию, мы знаем внутреннюю реализацию, у нас нет никакого полиморфизма, так как метод drawBrush работает строго с определенными данными. Реальное API будет комбинацией этих подходов. Что мы и наблюдаем в WinAPI. Часть функциональная, часть процедурная, часть ООП.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, grosborn, Вы писали:
G>>ООП ни разу не развитие модулей.
V>ООП — это концепция состояния как черного ящика. Эта концепция получила популярность и воплощение именно как модульность, ноги инкапсуляции растут оттуда.
ООП это концепция __поведения__. Концепция состояния это реляционная алгебра.
Здравствуйте, vdimas, Вы писали:
G>>Хендл со структурами данных не ООП, так же как шимпанзе не человек. Хотя они оба приматы. Я не знаю как тебе это объяснить, но вещи нужно называть своими именами. G>>Win API не ООП, епть.
V>Определение ООП в студию, наконец!
Интересно, как АПИ может быть программированием ? У тебя есть хороший ответ ?
> Набор процедур — z = createBrush(); setSlyle(z, COOLSTYLE); setColor(z, RED); draw(z); close(z); — это является ООП подходом. Соответствующий ему процедурный подход будет: > drawBrush(COOLSTYLE, RED); > В первом случае мы создаем внутреннюю структуру данных, мы понятия не имеем о том, как она устроена внутри, и через методы доступа устанавливаем интересующие нас характеристики результата. И с этой структурой данных у нас связан метод draw, который может рисовать очень и очень разные фигуры, в зависимости от того, какой идентификатор ему передали. > Во втором случае мы сразу же явно передаем всю информацию, мы знаем внутреннюю реализацию, у нас нет никакого полиморфизма, так как метод drawBrush работает строго с определенными данными. Реальное API будет комбинацией этих подходов. Что мы и наблюдаем в WinAPI. Часть функциональная, часть процедурная, часть ООП.
Тоже ведь подтасовываешь факты. Да, поздний процедурный стиль почти готов был к переходу к ООП, очень близок. И сделав несколько финтов двоемыслия ты превращаешь его в ООП, просто потому что тебе так проще его понять и запомнить. И если ты не будешь отбрасывать и забывать часть данных — тот же CloseHandle, SetDCBrushColor, PatBlt, которые являются процедурами работающими с разными областями данных, а не фанта-псевдо-методами мифических объектов, и рассматривать в целом без натяжек, то твои выводы ломаются.
Этот интерфейс был вылизан. И если бы на тот момент был ООП подход, то он был бы немного другой даже реализованный в процедурном стиле. Но на тот момент еще не была внедрена ООП методология, а действовала идеология процедурного стиля. И именно достижения процедурного стиля ты так старательно принимаешь за ООП подход.
Это если смотреть снаружи. А есть еще и под капотом. Так вот под капотом там совсем процедурно, все красивости старались сделать для публичного интерфейса.
Но vdimas в том смысле что ООП ничего нового тоже не согласен. Может не столько технически, сколько организационно. Те же буквы с новой методологией позволило нам перейти на более высокий уровень. Те же легко запоминаемые паттерны это высокий уровень абстракций и при процедурном подходе мы не смогли бы так же легко с ними работать.
> G>И сразу переврал. Это не object identifier, а внутренний идентификатор структур данных в ОС. Если бы это был object identifier, он так и назывался бы — object identifier. А он называется хэндл. > Он так и называется — object identifier. > > G>Есть еще более обобщающий пример — CloseHandle(). > Совершенно верно. > G>То есть то что одна единственная процедура освобождает разные структуры данных ОС по идентификатору, это ты считаешь ОО подоходом. > Конечно. Вместе со всем остальным прогрессивным человечеством.
Поискал прогрессивное человечество.
Поиск в сети статей описывающих windows handle как object identifier дает удручающий результат. Похоже "остальное прогрессивное человечество" это только сам Sinclair собственной персоной.
Здравствуйте, grosborn, Вы писали:
G>Тоже ведь подтасовываешь факты. Да, поздний процедурный стиль почти готов был к переходу к ООП, очень близок.
Это не поздний процедурный стиль. Просто на тот момент уже существовал ООП подход, который уже прекрасно показал себя в проектировании сложного GUI. Разработчики об этом подходе уже знали, но были вынуждены писать на обычном си, ибо это был на тот момент лучший язык для из задач. А даже если б и не было такого подхода еще — для задач создания сложного GUI как раз бы этот подход и изобрели бы.
Когда мы вызываем процедуру конструирования объекта, передаем ид этого объекта в универсальную процедуру рисования, а затем вызываем процедуру удаления объекта — это ни черта не процедурный подход. Ибо на процедурных языках это все крайне геморойно делать. Процедурный подход не поменялся — нужно что то нарисовать, мы сразу же передаем все данные для рисования в одну процедуру. Более того, этот подход не устарел и не устареет — ибо никакого смысла плодить объекты без необходимости во многих случаях нет. Хочу я нарисовать окружность — во многих случаях мне 100 лет без надобности плодить объект круг, затем его передавая. Во многих случаях вполне удобно будет сразу же передать все параметры.
G>И сделав несколько финтов двоемыслия ты превращаешь его в ООП, просто потому что тебе так проще его понять и запомнить. И если ты не будешь отбрасывать и забывать часть данных — тот же CloseHandle, SetDCBrushColor, PatBlt, которые являются процедурами работающими с разными областями данных, а не фанта-псевдо-методами мифических объектов, и рассматривать в целом без натяжек, то твои выводы ломаются.
А что по твоему представляет собой метод в ООП языках? Во что это все компилится и как это под капотом представляется? А компилится это в обычную процедуру, которой дополнительно неявно передается в зависимости от ЯП либо вообще напрямую адрес данных объекта (С++), либо ид, по которому эти данные можно найти (Java, C# и т.д). Так что де факто это все вполне себе методы, только без синтаксического сахара. Ну и я говорил уже — одна маленькая характеристика ООП, как типизация — да, увы, не соблюдается. Ибо вообще писали тогда на Си, где с типами было далеко не все идеально. Соответственно да, запросто можно было передать не тот ид, компилятор даже не ругнется, и ошибку получим на этапе выполнения только. Но на языках с динамической типизацией и сейчас так (хотя, де факто намного лучше, совсем левые данные в процедуру все таки не передашь, по крайней мере гарантированно конфликтов не будет между id объектов), но эти языки по прежнему считаются ОО.
G>Этот интерфейс был вылизан. И если бы на тот момент был ООП подход, то он был бы немного другой даже реализованный в процедурном стиле. Но на тот момент еще не была внедрена ООП методология, а действовала идеология процедурного стиля. И именно достижения процедурного стиля ты так старательно принимаешь за ООП подход.
Далее, если это бы сейчас сделали и по другому, то тоже можно было возразить — в то время методики эмуляции ООП были не так хорошо известны, где то разработчики старались оптимизировать по максимуму, где то схалтурили. Более того, уверен, что разработчики и не ставили перед собой задачу создать именно ОО API. Где можно было обойтись процедурным — обходились процедурным. Тяжелое время тогда было — слабое железо, неудобные среды разработки и языки.
G>Это если смотреть снаружи. А есть еще и под капотом. Так вот под капотом там совсем процедурно, все красивости старались сделать для публичного интерфейса.
А что под капотом — это вообще не важно. Если уж строго судить, то под капотом всегда будут команды и регистры процессора. То есть даже далеко не факт, что будет все даже процедурно, под капотом может вообще оказаться полная мешанина, где процедурами с функциями даже не пахнет — все через goto.
G>Но vdimas в том смысле что ООП ничего нового тоже не согласен. Может не столько технически, сколько организационно. Те же буквы с новой методологией позволило нам перейти на более высокий уровень. Те же легко запоминаемые паттерны это высокий уровень абстракций и при процедурном подходе мы не смогли бы так же легко с ними работать.
ООП да, привнес весьма много нового. Он именно что позволил поднять GUI на совершенно новый уровень.
> Когда мы вызываем процедуру конструирования объекта, передаем ид этого объекта в универсальную процедуру рисования, а затем вызываем процедуру удаления объекта — это ни черта не процедурный подход. Ибо на процедурных языках это все крайне геморойно делать. Процедурный подход не поменялся — нужно что то нарисовать, мы сразу же передаем все данные для рисования в одну процедуру. Более того, этот подход не устарел и не устареет — ибо никакого смысла плодить объекты без необходимости во многих случаях нет. Хочу я нарисовать окружность — во многих случаях мне 100 лет без надобности плодить объект круг, затем его передавая. Во многих случаях вполне удобно будет сразу же передать все параметры.
Я не понимаю почему для вас передача структуры это процедурный подход, а передача ссылки на структуру это объектный. Мне это кажется просто бредом. Потом я вижу очевидное отличие, процедура имеет доступ к структурам разного назначения с разным временем жизни в пределах модуля не через другие объекты, а через общедоступные индексные струтуры разного формата, имея с ними общую область видимости, а метод обращается только к локальным полям и структурам данных, а вне объекта только через контракты. У CloseHandle scope вообще получается не один модуль. PatBlt и CloseHandle для тебя это методы какого объекта?
Здравствуйте, Ikemefula, Вы писали:
I>ООП это концепция __поведения__.
Поведение отличается от безусловных реакций (чистых ф-ий) лишь тем, что каждая последующая реакция зависит от истории предыдущих. Так что позволь мне упорядочить твои мысли: бессмысленно обсуждать "поведение" без "состояния".
Здравствуйте, Ikemefula, Вы писали:
V>>Определение ООП в студию, наконец! I>Интересно, как АПИ может быть программированием ? У тебя есть хороший ответ ?
Здравствуйте, grosborn, Вы писали:
G>Поиск в сети статей описывающих windows handle как object identifier дает удручающий результат. Похоже "остальное прогрессивное человечество" это только сам Sinclair собственной персоной.
Плохо искали. http://msdn.microsoft.com/en-us/library/dd162957(v=vs.85).aspx
И, да, windows handle и HBRUSH — это разные вещи. Учите матчасть.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
> G>Поиск в сети статей описывающих windows handle как object identifier дает удручающий результат. Похоже "остальное прогрессивное человечество" это только сам Sinclair собственной персоной. > Плохо искали. http://msdn.microsoft.com/en-us/library/dd162957(v=vs.85).aspx > И, да, windows handle и HBRUSH — это разные вещи. Учите матчасть.
Тьфу ты, вот попал Глаз настолько замылился в свое время об это апи, что я эти странички даже не читаю, а ведь действительно как раз вот эти вот несколько вещей в графике в документации везде упоминались как объекты, эти объекты как раз исключения. Из всего многоообразия процедурного апи я случайно кликнул самый неудачный для себя минорный образец, да и забывать стал Надо было в другое место кликнуть.
Здравствуйте, FR, Вы писали:
FR>Ну если проектировать в ФЯ стиле скорее всего никакого SelectObject не будет.
Совершенно верно. Именно поэтому мы и говорим о том, что GDI в WinAPI спроектирован в OO-стиле.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, grosborn, Вы писали:
G>>ООП ни разу не развитие модулей.
V>ООП — это концепция состояния как черного ящика. Эта концепция получила популярность и воплощение именно как модульность, ноги инкапсуляции растут оттуда.
Состояние нужно исключительно для реализации поведения, следовательно ООП это просто вариант реализации поведения.
Здравствуйте, vdimas, Вы писали:
I>>ООП это концепция __поведения__.
V>Поведение отличается от безусловных реакций (чистых ф-ий) лишь тем, что каждая последующая реакция зависит от истории предыдущих. Так что позволь мне упорядочить твои мысли: бессмысленно обсуждать "поведение" без "состояния".
Поведение это обычно общий случай, в т.ч. зависимость от предыстории, и потому крайне странно напирать на то, что ООП это концепция состояния.
Здравствуйте, vdimas, Вы писали:
V>Поведение отличается от безусловных реакций (чистых ф-ий) лишь тем, что каждая последующая реакция зависит от истории предыдущих. Так что позволь мне упорядочить твои мысли: бессмысленно обсуждать "поведение" без "состояния".
Сильно думаю для начала надо упорядочить свое, прежде чем лезть упорядочивать чужое. Если для тебя ООП это концепция состояния, то думаю можно смело игнорировать все твои посты на тему ООП.
Здравствуйте, Tanker, Вы писали:
T>Состояние нужно исключительно для реализации поведения, следовательно ООП это просто вариант реализации поведения.
Поведения без состояния не бывает. Любой автомат — это функция с памятью по определению. И коль тебе захотелось сделать акцент на поведении, то преобразователь с памятью отличается от обычного ф-ного преобразователя именно наличием памяти и ничем больше.
Здравствуйте, vdimas, Вы писали:
T>>Состояние нужно исключительно для реализации поведения, следовательно ООП это просто вариант реализации поведения.
V>Поведения без состояния не бывает. Любой автомат — это функция с памятью по определению. И коль тебе захотелось сделать акцент на поведении, то преобразователь с памятью отличается от обычного ф-ного преобразователя именно наличием памяти и ничем больше.
Наличие памяти определяется исключительно поведением, соответсвенно и моделировать надо поведение. А как именно ты его смоделируешь — абсолютно не важно.
Глаз настолько замылился в свое время об это апи, что я эти странички даже не читаю, а ведь действительно как раз вот эти вот несколько вещей в графике в документации везде упоминались как объекты, эти объекты как раз исключения. Из всего многоообразия процедурного апи я случайно кликнул самый неудачный для себя минорный образец, да и забывать стал 
