Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>АбстрактныйТД это не абстрактный класс из ООП, и не в какой ООЯ он не встроен.

Википедии что ли начитался? Интерфейсы и абстрактные типы делают реализацию АТД в ООЯ элементарным занаятием. И то что абстрактный тип и АТД формально не одно и то же не означает, что в ООЯ нет средств реализации АТД.

Конечно всегда можно создать интерфейс не соответствующий определению АТД, но это ровным счетом ничего не меняет.

EP>АТД это фактически абстрактное описание математической структуры, такое же как например группа или моноид.

Не стоит заниматься демагогией. Мы на форуме программистов. Здесь чистые математические абстракции никому не интересны. Если ты не понял, что я сказал, просто прочти мои слова еще рез.

EP>Конкретный класс стэка, заточенный под единственный тип данных, без всяких виртуальных функций и абстрактных классов, уже сам по себе является воплощением АТД "стэк".

Похоже ты сам не понимаешь что такое АТД. Намек: стек он может быть и на базе СУБД реализован. Плюс это только пример. Не стоит упираться в частности рассуждая об абстракциях.

Здравствуйте, VladD2, Вы писали:

EP>>АбстрактныйТД это не абстрактный класс из ООП, и не в какой ООЯ он не встроен.
VD>Википедии что ли начитался?

Там в том числе. Если у тебя есть ссылки на другие определения — то приводи

VD>Интерфейсы и абстрактные типы делают реализацию АТД в ООЯ элементарным занаятием.

Вот только интерфейсы и абстрактные классы описывают только синтаксический интерфейс, в то время как основной частью АТД является семантика и математическая модель, а синтаксический интерфейс вообще вторичен.
Не говоря уже о том насколько вообще корректно выражение о реализации абстрактной математической структуры (не её конкретной модели, а именно самой структуры).

VD>И то что абстрактный тип и АТД формально не одно и то же не означает, что в ООЯ нет средств реализации АТД.

Приведи тогда конкретные средства "реализации" АТД в ООЯ.

EP>>АТД это фактически абстрактное описание математической структуры, такое же как например группа или моноид.
VD>Не стоит заниматься демагогией. Мы на форуме программистов.

Где ты увидел демагогию? Это моё понимание термина.

VD>Здесь чистые математические абстракции никому не интересны.

Может залудить опрос, делов-то. "Интересны ли вам математические абстракции"

Да даже если тебе они не интересны, это не означает что определения и терминологию можно прогибать как угодно под свои хотелки

EP>>Конкретный класс стэка, заточенный под единственный тип данных, без всяких виртуальных функций и абстрактных классов, уже сам по себе является воплощением АТД "стэк".
VD>Похоже ты сам не понимаешь что такое АТД.

А я думаю что ты не понимаешь — это терминологический спор.

VD>Намек: стек он может быть и на базе СУБД реализован.

Конечно может, я нигде не утверждал обратного. Это будет конкретным воплощением Абстрактного Типа Данных (или математической модели) "стек".

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Там в том числе. Если у тебя есть ссылки на другие определения — то приводи

Английскую вики отредактировал кто-то матаном головного мозга. Разговоры об абстрактных математических понятиях мало интересны для программистов. Для программистов АТД — это паттерн проектирования.

EP>Вот только интерфейсы и абстрактные классы описывают только синтаксический интерфейс, в то время как основной частью АТД является семантика и математическая модель,

Это треп бесполезный для программиста. Любой интефейс подразумевает некоторую семантику. От части ее можно выразить пред/пост-условиями, от части — документацией. В большинстве же случаев сематника и так очевидна. Вряд ли метод Push() у стека будет делать что-то отличное от того что мы с тобой под ним подразумеваем.

EP> а синтаксический интерфейс вообще вторичен.

Это вообще какой-то набор слов. Что такое "синтаксический интерфейс"?

Для программиста в АТД важны две идеи: абстракции (от реализации) и инкапсуляции. Но это базовые идеи ООП. Откровенно говоря идея наследования как раз вторична.

EP>Не говоря уже о том насколько вообще корректно выражение о реализации абстрактной математической структуры (не её конкретной модели, а именно самой структуры).

Очень даже корректно, если мы говорим о практическом программировании, а не просто хотим напыщенно по филосовствовать. Абстракции ради абстракции никому не интересны. Всем интересно получение выгоды из применения АТД. Она на лица и она согласуется с общими идеями ООП.

Просто надо понимать, что АТД придумали во времена когда ООП не было даже в проекте. Но цели были те же. И придумали их не абстрактные математики, а практики. Это уже потом под это дело заумную базу попытались подвести.

Прелесть АТД в том, что этот паттерн применим не только в ООЯ, но и в любом другом поддерживающем абстракцию данных. Скажем весь WinAPI (за редким исключением) построен на базе АТД.

EP>Приведи тогда конкретные средства "реализации" АТД в ООЯ.

Уже раз 20 это сделал. Сколько можно? Интерфейс и его реализация.

EP>Может залудить опрос, делов-то. "Интересны ли вам математические абстракции"

Залуди, если тебе это интересно. Но думаю, что тебя просто никто не поймет. каждый будет понимать под этим что-то твое и ты получишь чушь вместо ответа.

EP>Да даже если тебе они не интересны, это не означает что определения и терминологию можно прогибать как угодно под свои хотелки

EP>>>Конкретный класс стэка, заточенный под единственный тип данных, без всяких виртуальных функций и абстрактных классов, уже сам по себе является воплощением АТД "стэк".
EP>...Конечно может, я нигде не утверждал обратного. Это [b] будет конкретным воплощением Абстрактного Типа Данных[/b] (или математической модели) "стек".

Вот эти твои слова противоречат друг другу.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>АбстрактныйТД это не абстрактный класс из ООП, и не в какой ООЯ он не встроен.
EP>АТД это фактически абстрактное описание математической структуры, такое же как например группа или моноид.

Разумеется. Но ООП как раз и даёт эту поддержку АТД

Здравствуйте, LaptevVV, Вы писали:

LVV>ООП имеет наследование, АТД — нет.

Если так, то это очень похоже на то, что делается в 1С. Там есть набор базовых типов ("Справочник", "Документ", "Регистр бухгалтерии" и т.п.), и от них можно порождать собственно те виды данных, с которыми потом все и работают. Например, Справочник.БанковскиеСчета, Документ.ПлатежноеПоручениеИсходящее, РегистрБухгалтерии.Управленческий. А вот накрутить ещё один уровень иерархии — тут жёсткий облом. Сделать что-то вроде Справочник.БанковскиеСчета.Расчетные и Справочник.БанковскиеСчета.Депозитные не получится. Нет даже такого пункта в меню.

Результат — потрясающий. С одной стороны, немножко гложет тоска по отсутствующей возможности вынести какую-нибудь логику в базовый класс, и от потребности в массовом копипасте приходится спасаться динамической типизацией. Но с другой стороны проблема построения иерархий ("что чему является базовым классом? окружность эллипсу или эллипс окружности?") отсутствует напрочь. У народа есть чёткое представление о критериях выбора базовых типов, и количество архитектурных ошибок в духе "не от того унаследовались" стремится к нулю. Вопреки банальной логике и очевидному здравому смыслу системы в результате получаются проще (и в разработке, и в использовании, и в развитии, и в сопровождении), функциональнее, надёжнее и, что особенно удивительно, шустрее.