Объяснение концепции АТД

[Utkin]

Ну Вы даете - изначально строите неверное предположение и потом его же с помощью самого себя и оправдываете.
Итак, чтобы не плавать, дайте определения:
ООП
интерфейс
АТД
Без ссылок одного на другое.
Вообще звучит смешно - интерфейс это набор методов. АТД это набор методов. В с# все есть методы. Следовательно мой хэлоуворд там будет АТД, методом и интерфейсом, ну и смысл? А вот в Делфи тот же по смыслу и максимально приближенный код, но не оформленный в классе не будет АТД и не будет интерфейсом так как методом не является. Бред какой-то.

[Igor95]

Сообщение от Utkin

Ну Вы даете - изначально строите неверное предположение и потом его же с помощью самого себя и оправдываете.
Итак, чтобы не плавать, дайте определения:
ООП
интерфейс
АТД
Без ссылок одного на другое.

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

[Utkin]

Ну вот и славно. Вот видите здесь Вы четко указываете что АТД это тип данных. То есть синонимичности в определении АТД и интерфейса нету. Так и не придумывайте способы смешать их воедино.

[Igor95]

Да, но ведь в википедии сказано, что АТД - интерфейс... что тогда? неправильность определения в википедии?
Некая синонимичность в АТД и интерфейс просматривается:
и там и там - операции.

[Utkin]

и там и там - операции.

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

[Igor95]

Хорошо, т.е когда советуют думать об АТД, а о классах после построения модели АТД, подразумевают, что я должен обеспечить удобство и правильность обработки данных? При чем же здесь тогда абстрактность? Где она фигурирует?
Я понял только то, что АТД != интерфейс... получается, что сначала я должен построить модель АТД, а далее применить концепции построения классов (где нужно и правильно применить наследование/полиморфизм). Т.е АТД диктует правила построения сущности, которая была бы удобным и правильным инструментом обработки данных?

[Utkin]

Где она фигурирует?

Она здесь напрямую и связана. АТД прячет внутри себя внутри устройство своего типа данных. Как реализован список? А кто его знает? Может там память через указатели выделяется, может быть динамический массив юзается. Но это все пофиг, потому что оперируя списков Вы физически не перемещаете сами объекты в памяти - Вы перемещаете указатели на данные объекты.
А это:
1) Позволяет (теоретически конечно) хранить в списке объекты разных типов. Вам ведь не надо в списке что-то делать с самим объектом. Но Вы можете хранить там и массив и число и строку. Вот Вам и абстрактность. Реальным примером может служить вектор из Scheme - это такой одномерный массив, который чихал на тип своих элементов (в большинстве других языков программирования как Вам известно массивы могут содержать только однотипные элементы).
2) Это относительно быстрые операции и они также не зависят от самих данных, так фактически в списке Вы работаете с указателями/индексами объектов.

[Igor95]

Т.е абстракция заключается в том, что мы абстрагируемся от деталей реализаций (внутри может быть как угодно). Так, тогда концентрируемся мы на интерфейсе??
АТД - список (интерфейс: добавить, удалить, найти).
Конкретная реализация АТД: односвязный список (на основе указателей), при этом интерфейс не меняется. Меняется лишь реализация...
Т.е АТД - набор данных и операций, служащих одной цели ((с) Стив МакКоннелл).

[Utkin]

Так, тогда концентрируемся мы на интерфейсе??

Что же Вас из крайности в крайность-то швыряет? Класс вполне себе жизнеспособен без интерфейса в той форме, которую Вы приводите (я еcли заметили даю общее описание интерфейса). То есть интерфейсы требуются далеко не всегда и можно писать классы без интерфейса (и без полиморфизма, а в делфи и без инкапсуляции). Поэтому не на чем таком мы не концентрируемся. Это детали реализации - концентрируйтесь на проектировании

[Igor95]

Хорошо, спасибо, что уделили время :-)
Кое что прояснилось, буду дальше грызть :-) может получится еще глубже вникнуться в эту идею :-)