Здравствуйте, 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
