Здравствуйте, 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>Что сказать-то хотел?
Хотел сказать, что класс ООП инкапсулирует в себе, в единой сущности, как состояние, так и код это состояние изменяющий. Хотя теперь я понял, что вы не видите особой разницы между классом и глобальными переменными, как между современными автомобилями и первыми тарантасами. Понятно, почему вы не поняли, что я сказал.
